Padding on back to back favorites specific issue

[waynedunham]

I've seen this for quite a while and just noticed the specific conditions where it will crop up.

I am not sure how long this has been in the code, whether back in V7 and continued onto V9 or something that entered in the V9 updates/changes.

Here is the issue. On certain channels/shows they will air a new episode and then repeat the new episode in the very next time slot. (The Last Ship on TNT is a specific example).

Whenever this happens SageTV will not put on the post padding even though nothing is being recorded next either on that channel, nor on that tuner. NOTE: I do have remove padding on back to back recordings (same channel) set.

i.e. The Last Ship airs at 9pm as a first run and at 10pm the exact same "new" episode airs. So my favorite for The Last Ship records at 9pm, but stops at 10pm instead of padding an extra 2 minutes. There is nothing recording at 10Pm on that tuner, and in fact there are other tuners free so a conflict can't be the issue.

There are other examples on other shows/networks that have this same behavior. If it is a different episode, or different show SageTV V9 will do the proper padding and leave it in if nothing is recording in the next time slot and/or a tuner is free. It will strip the padding if it is recording the next show on that same channel or it needs the tuner to record something else.
I am running the latest Windows version, but this has been in there for a long time, possibly even back in V7?

As I said I have seen this crop up on occasion since at least the initial V9, and probably back to V7, but just made the connection on the conditions that cause it to happen.

[Narflex]

This is a known issue. The problem stems from that when it determines if it should be removing the padding or not for a back-to-back favorite, it only checks if the one following it has been watched or not....it doesn't go to more extensive measures like checking the schedule or existing recordings because that would induce too much of a penalty for these frequently used API calls and result in performance problems (or at least that was the reason I never changed that code, it may actually be able to handle it without much issue if somebody wanted to try changing that and see how it results).

[waynedunham]

I guess that explains a lot of these recordings over the years. I always figured that either the tuner was needed so it couldn't do the post padding.

Sure would be nice to see this addressed at some point during code work. To me it would seem like just another "if/then" type operation during the normal remove padding on back to back testing for the scheduler while it figures whether to put the post padding on the end of the recording.
I'm sure I'm probably over simplifying that, speaking from a non-coders mind.

[texneus]

Oops, LOL. I just noticed this the first time a few days ago myself setting up to record "The Vietnam War" which for some reason our PBS station is repeating episodes back to back. When I started digging I found other shows and created an issue on Github (issue 363 if you want to track it).

I did look to see if others reported this problem but it seems like the forums are too fractured. We have "SageTV Software", "SageTV Linux", "SageTV Unraid", "SageTV Open Source" and "Open Source Development" all seem to be places applicable for reporting problems. Apparently, I didn't look here...

[Monedeath]

Originally Posted by Narflex

This is a known issue. The problem stems from that when it determines if it should be removing the padding or not for a back-to-back favorite, it only checks if the one following it has been watched or not....it doesn't go to more extensive measures like checking the schedule or existing recordings because that would induce too much of a penalty for these frequently used API calls and result in performance problems (or at least that was the reason I never changed that code, it may actually be able to handle it without much issue if somebody wanted to try changing that and see how it results).

Considering what most people use record padding for, that seems slightly backwards. I'd think the only thing the scheduler would be concerned about is if the next program is going to record as it's own entry. Watched/not watched, already recorded(episode)/not recorded isn't relevant to that use case. The user simply wants to be certain something is recording that channel 1 minute after the program's scheduled end time.

Edit although in a serial schedule building process I can see where the shortcut may have happened, it(watched status) still seems an odd basis. Beyond the obvious that a "watched" show would never be flagged for automatic recording so some overhead gets skipped. Hard to check if a following show is scheduled when the scheduler hasn't made it there yet.

"Easy logic" (easy being very relative) Would probably be to either do a "first pass" scheduler run without padding, then add it in from there on a second pass, reshuffling as conflicts pop up and resolve. Or shift the "post-show" padding to being something that is added later on when "remove padding" on back to back is selected. (So that the following show should already be scheduled or not for recording by then) these are adjustments EnterNoEscape is probably grappling with on one of his other SageTV projects.

[EnterNoEscape]

Originally Posted by Monedeath

"Easy logic" (easy being very relative) Would probably be to either do a "first pass" scheduler run without padding, then add it in from there on a second pass, reshuffling as conflicts pop up and resolve. Or shift the "post-show" padding to being something that is added later on when "remove padding" on back to back is selected. (So that the following show should already be scheduled or not for recording by then) these are adjustments EnterNoEscape is probably grappling with on one of his other SageTV projects.

I am still working on this. I was close to committing and then some flags were removed from the main code base, so now I have to clean them out of my code too. Also there was a request to modularize everything which what I did isn't completely compatible with since I was designed based on the current model of singletons. I spent a few weeks fiddling around, trying to adjust the code so that it was more compatible with running tests and it was actually really hard to get rid of the global state problems because of all of the dependencies on singletons, so I left off there and then life got really busy.

[Monedeath]

Originally Posted by EnterNoEscape

I am still working on this. I was close to committing and then some flags were removed from the main code base, so now I have to clean them out of my code too. Also there was a request to modularize everything which what I did isn't completely compatible with since I was designed based on the current model of singletons. I spent a few weeks fiddling around, trying to adjust the code so that it was more compatible with running tests and it was actually really hard to get rid of the global state problems because of all of the dependencies on singletons, so I left off there and then life got really busy.

Well, on second thought, given Narflex has that wiz.bin that used to take 3+ days to process(and would be bogging down the scheduler), a first/second pass approach would have been bad for them unless another path for bugs was introduced to prioritize running that "second pass" on a recording that just started... Which could start the whole thing over again.

On another note, I feel like trying to compensate you for your time on things, but I'm not finding an option to throw money at you.

[EnterNoEscape]

Originally Posted by Monedeath

On another note, I feel like trying to compensate you for your time on things, but I'm not finding an option to throw money at you.

I suppose this isn't a bad problem to have, but it feels like people just want to throw money at me. Part of the reason why I don't do this is because my intention is to help the community, not profit from it. However, this is a popular request, so I'll consider adding something to my signature.

[wnjj]

Originally Posted by EnterNoEscape

I suppose this isn't a bad problem to have, but it feels like people just want to throw money at me. Part of the reason why I don't do this is because my intention is to help the community, not profit from it. However, this is a popular request, so I'll consider adding something to my signature.

With as much time and effort you've spent, I'd hardly call it "profit."

Just so long as people don't get demanding.

[NetworkGuy]

Originally Posted by EnterNoEscape

I suppose this isn't a bad problem to have, but it feels like people just want to throw money at me. Part of the reason why I don't do this is because my intention is to help the community, not profit from it. However, this is a popular request, so I'll consider adding something to my signature.

Use it as funding source to pay for new test equipment.

I would contribute to that.

[Monedeath]

Originally Posted by wnjj

With as much time and effort you've spent, I'd hardly call it "profit."

Just so long as people don't get demanding.

Indeed, the amount of man-hours he's probably put into it, at the hourly rates he'd probably be able to net otherwise(even if he's normally salary), he's probably out thousands of dollars worth of "opportunity cost" as it is even before touching equipment.

A few hours here, a few hours there, a major coding binge over here, so and so forth, those hours start to add up.

The problem is the other group of people who love to feel entitled after throwing $2 into the pot.

[waynedunham]

Nothing new/different to report as far as any change to this goes.

Just that I'm seeing it more and more in my scheduled recordings now that I know what I'm looking for. Explains so many past recordings (for years!) that didn't have "proper" padding on them.

So I'm spending more time in my scheduled recordings setting these particular recordings to manual so it prompts me to whether to add padding or not. Of course all the extra time muddling around in the scheduled recordings is causing even more java heap overruns than before. Well, that and all the extra processing required to fit all the returning and new shows in to the fall schedule.

[SHS]

Are both getting slow load time when you first SageTV server ?.

[Monedeath]

This specific issue isn't the reason I opted for throwing more tuners at SageTV instead. But it certainly does make me glad I did go the route of preserving the padding on back-to-back recordings instead. Even if the reason was for archival reasons and ensuring a continuous file. It did effectively double the number of tuners needed, but it seems to have mitigated a number of other headaches.

Maybe an interim(or even more permanent) fix (prior to EnterNoEscape's overhaul for 1 tuner, multiple streams) for those who don't want to go that route would be to shift the "preserve padding" flag to the recordings/favorites themselves and make the current (global) setting the default which can be overwritten on a case by case basis. Even though I currently preserve padding on everything, that doesn't mean I need or even want to on everything I record.

[Zogg]

Were these changes to the padding ever implemented? I continue to see padding issues where there are no conflicts or even other tuner usage yet the recording engine ignores the manual padding I've added.

[nyplayer]

Originally Posted by Zogg

Were these changes to the padding ever implemented? I continue to see padding issues where there are no conflicts or even other tuner usage yet the recording engine ignores the manual padding I've added.

There is a setting that will remove Padding on back to back recordings on the same channel. If you want to always keep padding you need to set that to NO it will use more tuners but will keep padding.

[SHS]

Yup nyplayer is rigth