Chase-play unreliable

[Cameron]

Hello,
I have posted in the Whirlpool Australian forum about a problem two users are finding with chase-play.

The symptom is that trying to chase-play a current recording sometimes fails, and the toppy will only jump to live. Rewind or skipping back is not possible.

There are a few red-herrings in that post, so the summary so far is that the common factors are:

• It only happens when the recording is the second of two consecutive recordings on the same channel.
• Problem observed with SE versions 5.4e, 5.5, 6.0b
• Not observed if SE is not installed.
• Still occurs if the SE TAP is stopped at the time of recording.
• The inf files are very small (I think that means there is no preview still image) but this might just be a coincidence.

I have a 7170 and Matt (the other user with the problem) has a 2400.

The point about the toppys crashing and rebooting was just a symptom of using jdaskip to try to jump back to the start of the recording. John (jda) supposes it is because the recording state is invalid at that time.

I tried to see if it was the presence of overlap due to the padding in the timers, but if I manually set the first stop and second start times to the same value, the problem still occurred.

So,

1. is this a known problem?
2. can anybody suggest anything to help track it down or work around it?

[Twilight]

There are a few red-herrings in that post, so the summary so far is that the common factors are:

• It only happens when the recording is the second of two consecutive recordings on the same channel.
• Problem observed with SE versions 5.4e, 5.5, 6.0b
  

this "problem" you have with every version of SE, because SE uses a firmwarehack that it is possible to record two recordings on the same channel overlapping. this is not possible when you don't use SE. without SE the firmware just starts the second record after the first is finished...

twilight

[Cameron]

OK, thanks,
So is there a workaround that does not totally remove any padding?
For example, I have a search that records multiple programs in one week and some days it is followed by others recordings. So removing padding completely is not a good option for the days it is not followed by another recording.

I see the option to merge adjacent recordings, but that is not convenient in my case.

Is there an option to remove padding when two programs are adjoining? I would rather potentially miss a second or two than risk having the machine reboot partway through a recording.

Cameron.

[Roemer]

What do you mean with "padding" - is it the extra time before an after then recording?

[camello]

Or you could allow combining the consecutive timers. So there will be only one recording and chase-play should work.

[deangelj]

Does that mean that maybe the contents of the .inf or the .nav files may be invalid for overlapped recordings when running SE? My skip TAP (jdaSkip) depends on the contents of those to know how far to skip

[Cameron]

[quote="Roemer"]What do you mean with "padding" - is it the extra time before an after then recording?[/quote]
yes - I think the Deutsch is "vorlauf" and "nachlauf"

[quote="camello"]Or you could allow combining the consecutive timers. So there will be only one recording and chase-play should work.[/quote]
This gives other problems. For example, set up a search recording for one program and some weeks later set up the recording for the program before it.
If they are joined then only one program name appears in the file list (I assume the first name applies), and so the second program "disappears". This will be hard enough for my old brain to keep track of, but if the recordings are for two different people in the house then I can see too many problems knowing what to watch and when to delete.

[Twilight]

when you combin two timers, the file will named with both timer names.
and when you want to see this records one or two weeks later it makes no difference if they was overlapping or not while they was recorded...

twilight

[FireBird]

[quote="deangelj"]Does that mean that maybe the contents of the .inf or the .nav files may be invalid for overlapped recordings when running SE?[/quote]
The first one needs to be patched so that the second recording even starts. This gets fixed after the recording finishes but the firmware can?t identify the recording anymore and therefore the chase play fails.

[DeltaMikeCharlie]

[quote="FireBird"]The first one needs to be patched so that the second recording even starts. This gets fixed after the recording finishes but the firmware can?t identify the recording anymore and therefore the chase play fails.[/quote]
Could you copy the unpatched INF and call it "temp recording" and then create hard links to the MPG/REC and NAV files also calling them "temp recording"? Chase-play the links and not the original. The firmware should see an intact non-hacked INF and play it.

I experimented with a similar method whilst developing INFplus and easily had several "real" INF files with different names all pointing to matching "linked" MPG/NAV files all eventually pointing to the same underlying actual MPG/NAV.

[FireBird]

The timer structures get patched before the timer fires. As a result, the inf file contains a channel setting, which doesn’t match the channel setting of the recording channel until it gets fixed by SE after the recording finishes. It is even a bit more complicated because with that “simple patching”, the Toppy would reboot if you try to chase play a overlapped recording but I can’t remember the exact sequence of events at the moment.

[Cameron]

You (the SE developers) have clearly looked at this in a lot of detail, and i suppose there must be reasons why Topfield themselves have not fixed it.

Since there are options to merge adjoining recordings, then the TAP already has code for identifying these instances. Would it be possible to have an option to simply zero the padding for overlapped recordings?
I had a situation tonight where I manually removed the padding in the search definitions, and it seems to have removed the problem.

[quote="Twilight"]when you combin two timers, the file will named with both timer names.[/quote]
That is good to know. We may need to wait for a bit of scrolling to see the second name but there should be a hint in the first part of the name displayed.