747 replies to this topic

[MiLo]

You know how long the commercial break is, BEFORE you skipped it?

Yes. In the Netherlands, the commercial breaks have a pretty constant duration. In the few exceptions to this rule, they are so nice as to display "Back in one minute" at the start of the commercials, so that you know that a single "6" will get to to where you were going.

I don't see how living in a certain country relates to being able to predict lottery numbers, but since you suggested it, it'd be nice to know how that relates!

[littlesat]

But let's back to the timeshift troubles

[mik9]

OK, let us close the skipping/rewinding issue with the closure that possible new timeshift must definitely have skipping and for some old school guys who like the slow and imprecise "analog" way in digital era, would be good to keep REW/FF in timeshift too;-)

As I am using Permanent Timeshift, I do not see the behavior described here regularly; only for 3 channels, if I go back less than cca 20 seconds, unpause and try to skip back again, I get to real time. It is interesting that these 3 channels are from one content provider that is using not very common SD format 704x576 instead of regular 720x576. Maybe this could be some hint in troubleshooting this issue.

[littlesat]

It could be related by the way the provider put the PTSs inside the stream...

[pieterg]

more likely, those are lower bandwidth channels, so e2 is more likely to assume 'EOF' because it's nearer to the end of the file.

[mik9]

I will check the bandwidth comparing to other channels that are working. Anyway, this did not happen some time ago.

[mik9]

So I found the following: I have this issue for all channels with bitstream below approx. 1500 Kb/s (usually SD channels broadcasted in MPEG-4). I did not notice this before last update that I did approximately 14 days ago (before I had last update somewhere in December).

[littlesat]

That was indeed what pieterg was describing and i also did suggest previously,,,
Te bof begin of file detection needs to be added for this,,. Including the what makes it more complecated... Take in account if there might be a previous.slice..

[betacentauri]

After several hours setting up the building environment I'm now ready for programming/testing. I have reverted your patch
http://openpli.git.s...a048b5b0dcf1aa6
but this makes almost no difference (perhaps it's a little bit better but perhaps it's only imagination.

I currently don't understand this:
If seeking backwards works the first time, I can afterwards seek back without problems even when I try to go before start of file
(it stays at start of file and don't switch to live TV). So first seeking is in a way special.

[pieterg]

I've looked what happens with timeshift, and it seems this is what is going on:

as long you are closer than m_blocksize to the end of the file, you should not try to skip, because you will jump to the live point.
m_blocksize is 188*1024 nowadays (it might have been a bit smaller in the past, so the problem might have been less obvious)
So on a low bandwidth channel, it takes a bit of time, when you start the timeshift, before the file has grown big enough for e2 to comfortably skip around in it.

You can see when it's 'safe', by looking at the e2 output, as soon as the

wait for driver eof timeout
wait for driver eof timeout
wait for driver eof timeout
wait for driver eof timeout
wait for driver eof timeout
wait for driver eof timeout
wait for driver eof timeout

have stopped, you're good to go.
Now you can skip forward (as long as you stay 188*1024 bytes from the end of file) and back even to 'before' the start of file, without problems.

However, as soon as you skip to within 188*1024 of the end of file, the "wait for driver eof timeout" messages will start again, and the next skip will set you back to the live point, and you'd have effectively lost the timeshift buffer.

With this knowledge, does this explain what you see?

[pieterg]

actually, the timeshift is not 'lost' when it jumps to the live point, you can still go back with the rewind button.
The skip buttons however, will not work at the live point.
As soon as you've wound back away from the live point, with the rewind button, the skip buttons will start working again.

[greatred]

actually, the timeshift is not 'lost' when it jumps to the live point, you can still go back with the rewind button.
The skip buttons however, will not work at the live point.
As soon as you've wound back away from the live point, with the rewind button, the skip buttons will start working again.

on page 3 of this thread I already confirmed the same:

[list]
[*]press pause on the remote
[*]after waiting a while (5 seconds is the minimum time i was trying to reproduce - but same misbehavior has been observed also with 60 minutes "pause") and pressing play the playback jumps to real time.
[*]the counter resets to 0:00 but I`m still able to rewind to the beginning of timeshift file.(the counter gets adjusted accordingly)
[/list]

Edited by greatred, 27 January 2013 - 19:39.

[betacentauri]

Hi pieterg,

that corresponds to what I saw. But I still don't understand why skipping backwards causes a jump to live tv. Skipping backwards shouldn't be a problem.
I added some debug messages to the filepush thread. I can see that the jump backwards works:

current_offset 13475840, new_offset 13475840, last_offset 13475840
current_offset 13475840, new_offset 6595228, last_offset 13475840
current_offset 6691484, new_offset 6691484, last_offset 6691484
current_offset 6787740, new_offset 6787740, last_offset 6787740
...

But then one threads seems to send the EOF event.

eDVBChannel: End of file!													  
timeshift EOF, so let's go live												
SwitchToLive					

Which thread it is, I currently don't know. Most probably the timeshift file read thread. Sending EOF can only occur when m_send_pvr_commit is false.

But I also don't understand this (filepush.cpp):

		/* in stream_mode, we are sending EOF events
138									over and over until somebody responds.
139								  
140									in stream_mode, think of evtEOF as "buffer underrun occurred". */
141						 sendEvent(evtEOF);
142
143						 if (m_stop)
144								 break;
145						 if (m_stream_mode)
146						 {
147								 eDebug("reached EOF, but we are in stream mode. delaying 1 second.");
148								 sleep(1);
149								 continue;
150						 }
151						 else if (++eofcount < 10)
152						 {
153								 eDebug("reached EOF, but the file may grow. delaying 1 second.");
154								 sleep(1);
155								 continue;
156						 }
157						 break;

Why do you send EOF immediately and not after 10 tries (eofcount)?

I'll debug now a little bit more.

Edited by betacentauri, 27 January 2013 - 19:49.

[pieterg]

that corresponds to what I saw. But I still don't understand why skipping backwards causes a jump to live tv. Skipping backwards shouldn't be a problem.

skipping means clearing the decoder buffers, so they are immediately empty. Combined with the fact that e2 believes it's at the end of the file (or rather, less than one blocksize away from it), that's an 'end of playback' condition.

[betacentauri]

Ah, now I understand. Thanks pieterg!!

I have a "simple" solution for this. The user requested a skip, so why sending EOF event in this case? I see no reason for this.
So change filepush.cpp from:

128										 default:
129												 eDebug("wait for driver eof aborted by signal");
130												 /* Check m_stop after interrupted syscall. */
131												 if (m_stop)
132														 break;
133												 continue;
134								 }
135						 }
136						
137								 /* in stream_mode, we are sending EOF events
138									over and over until somebody responds.
139								  
140									in stream_mode, think of evtEOF as "buffer underrun occurred". */
141						 sendEvent(evtEOF);
142
143						 if (m_stop)
144								 break;
145						 if (m_stream_mode)

to this:

128										 default:
129												 eDebug("wait for driver eof aborted by signal");
130												 /* Check m_stop after interrupted syscall. */
131												 if (m_stop)
132														 break;
133												 continue;
134								 }
135						 }
136						
137								 /* in stream_mode, we are sending EOF events
138									over and over until somebody responds.
139								  
140									in stream_mode, think of evtEOF as "buffer underrun occurred". */
142
143						 if (m_stop)
144								 break;
141						 sendEvent(evtEOF);
145						 if (m_stream_mode)

Or only sending EOF if eofcount=10.
I cannot estimate if it does have side effects, but a first test worked here.

[mik9]

Guys, thanks for looking into this. If betacentauri's solution works and could be incorporated, it would be great.

@littlesat: Thanks for solving the bug after opening Movie Selection while timeshifting. I had problems with Permanent Timeshift that it sometimes stopped to respond to skip keys and only REW key worked, not even FF. I just recently identified that it happens always after I open Movie Selection dialogue and exit from it. I was just to investigate it deeply and just today I read commits in GIT and found out that you did something about this. Anyway, your solution did not work for Permanent Timeshift so I just commented out InfoBarBase.__init__(self). Is this class useful for something in Movie Selection? Can we get into any troubles when this is not initialized?

[littlesat]

Yep... That disables a feature in the movielist completely... Possibly it must be arranged in pts that the movieplayer is also aware of a pts active

[mik9]

What features are disabled? As I did not find anything that would not work for me.

[littlesat]

E.g. Playing files while movieplayer is visable... The next file is not played as soon the currently player reaches eof.

Edited by littlesat, 29 January 2013 - 18:32.

[betacentauri]

Hi littlesat,

did you look at my solution? I should be also able to send you a patch file, if you like.
I'll do now a long time test. All short tests didn't show any problems.