747 replies to this topic

[betacentauri]

So removing the seek in python fix it?

I have removed the seek in c++ part (haven't tested it with removing python seek). That worked. But it don't solve the general problem. So it can occur again and again if e.g. load is high or under other circumstances.
So I would like to start event processing manually. That would be an always working solution.

[mik9]

I do not know if I exactly got your problem here as I am using PTS. But I also had some problems when I wanted to define key for skipping back 15 secs and release the pause as it was not so simple like activateTimeshiftEndAndPause(), doSeekRelative(-config.seek.selfdefined_13.value * 90000) and then just setSeekState(self.SEEK_STATE_PLAY). This put me back to live TV immediately so I had to use another 2 functions and 1 timer to make the trick. If you are interested in this, I can paste the whole solution here, even translated into English (as I usually use mother tongue for variables, etc. to distinguish my own insertions easily:-)

[pieterg]

So I would like to start event processing manually. That would be an always working solution.

how do you see that?
Events are always processed. Except when the mainloop is blocking (because of some suboptimal constructions in the user interface)

[Tralien]

which PTS do you use? do you have a link to ipk file?
i tried several pts plugins called 1.2a and 1.2b, but it never worked fine for me...i sometimes can only go back with 2x speed and cant jump o its sometimes useless.

[littlesat]

The stepback 15 seconds is processed when in timeshift live modes... but livemodes is not seekable and therefore it will not be performed...

[betacentauri]

So I would like to start event processing manually. That would be an always working solution.

how do you see that?
Events are always processed. Except when the mainloop is blocking (because of some suboptimal constructions in the user interface)

Have you read my post (http://openpli.org/f...post__p__333571)?
The problem is, that event processing is too late (after unpause) and in play mode EOF event means "switch to live tv". I want to process the events before unpausing to avoid the problem.
Or do you have another idea to suppress EOF event in this case?

Edited by betacentauri, 11 February 2013 - 12:49.

[pieterg]

are you sure that the EOF event is generated when the playback is still paused?
I suspect that the EOF actually occurs when the decoder is unpaused, and finds its buffer empty.
So trying to process events before unpause, might not help.

[betacentauri]

I'm quite sure that the first seek (in switchToTimeshift) generates the EOF event.
I'll test it again this evening and post a log (without my debug stuff ).

[mik9]

which PTS do you use? do you have a link to ipk file?
i tried several pts plugins called 1.2a and 1.2b, but it never worked fine for me...i sometimes can only go back with 2x speed and cant jump o its sometimes useless.

I originally started with version 1.01 or 1.02, I already do not know as I do my own adaptations of this plugin. But I have never had any problem with REW/FFW or skips except for the bug when you go to MovieSelection and back. But this was recently addressed in OpenPLI. Anyway, the last version that I used is 1.2 from here:
http://schwerkraft.e...dfa5c64acb98cfb

[betacentauri]

Ok, here is the log:
Line 79: Start of timeshift
Line 209: Unpause
Line 255: Seek to live tv
Line 336: Rewind button pressed
Line 354: 1. seek from c++ part
Line 365: "wait for driver eof ok" -> eof event generated
Line 398: 2. seek from python part
Line 421: activateTimeshiftEnd is called a second time (from python part?)
Line 425: unpause is executed because timeshift is active (see InfoBarGenerics)
Line 432: "eDVBChannel: End of file! timeshift EOF, so let's go live" -> switch back to live tv

-> Event is processed after unpause

Attached Files

•  log15.txt   16.45KB   3 downloads

[betacentauri]

@pieterg: Well, the first seek is executed in play mode (see servicedvb.cpp switchToTimeshift). Can that cause the eof?

Edited by betacentauri, 11 February 2013 - 18:44.

[pieterg]

@pieterg: Well, the first seek is executed in play mode (see servicedvb.cpp switchToTimeshift). Can that cause the eof?

not likely, because the thread will be stopped during a seek (m_stop is nonzero), any EOF conditions will be ignored till after the thread restarts.
However, there might be a race there, m_stop being set just after EOF has been triggered.

[mik9]

This is exactly what I wrote about before, that if after activateTimeshiftEnd (or activateTimeshiftEndAndPause that is just calling the same function) you immediately try to unpause, it goes to live TV. It obviously need some time to process something and only then it works. So I introduced timer with 1000 msecs delay and only then I unpause. It works flawlessly. Maybe it could be speed up by few msecs but I did not try to go to extreme as it will probably depend on things like bitrate and 1000 msecs looks like safe but still quick enough solution.

Edited by mik9, 11 February 2013 - 19:09.

[betacentauri]

@mik9: I would like to get down to the root of the trouble and fix there the problem. Adding timer, reorder seeks (this helped for me),... can fix the problem but perhaps not in all cases. But I'm still learning and don't know the sources as good as pieterg.

@pieterg: I see 2 nice solutions:[list=1]
[*]Prevent EOF event. Is it easily possible to "ask" the decoder, if he is in pause mode? Then we could prevent sending EOF in pause mode.
[*]Process EOF before unpause
[/list]
For both I see no easy way to do it.

And there are ugly solutions like, remove seek in c++ part (perhaps it also works with the seek in python part), add timer, pause before seek(with -90000) in c++ part,... but as said before this might not fix the problem in all cases.

Do you have another idea?

[pieterg]

just as a test, does this improve the situation?

Attached Files

•  no_eof_before_write.patch.gz   403bytes   16 downloads

[betacentauri]

Hm, that might work well. I can test it tomorrow (in the evening).
Thanks!

[betacentauri]

With the patch I can't seek back to live tv, because the written variable is set back to false during seek and so EOF is not recognized.

But this works for me:

diff --git a/lib/base/filepush.cpp b/lib/base/filepush.cpp
index e9496f9..265f48b 100644
--- a/lib/base/filepush.cpp
+++ b/lib/base/filepush.cpp
@@ -37,6 +37,7 @@ void eFilePushThread::thread()
		int eofcount = 0;
		setIoPrio(prio_class, prio);
		int buf_end = 0;
+	   bool ignore_eof_after_first_read = true;

		size_t bytes_read = 0;
		off_t current_span_offset = 0;
@@ -141,7 +142,8 @@ void eFilePushThread::thread()
								   over and over until somebody responds.
								  
								   in stream_mode, think of evtEOF as "buffer underrun occurred". */
-					   sendEvent(evtEOF);
+					   if (ignore_eof_after_first_read)
+							   sendEvent(evtEOF);

						if (m_stream_mode)
						{
@@ -189,6 +191,7 @@ void eFilePushThread::thread()
						if (m_sg)
								current_span_remaining -= buf_end;
				}
+			   ignore_eof_after_first_read = false;
		}
		sendEvent(evtStopped);
		eDebug("FILEPUSH THREAD STOP");

Does anybody want to test it? I can provide a e2 binary for et9x00.

[betacentauri]

Wait! Normal recorded file don't stops at end of file. Currently don't know why, because I see more than one eof in log:

wait for driver eof ok
reached EOF, but the file may grow. delaying 1 second.
wait for driver eof timeout
wait for driver eof timeout
wait for driver eof timeout
wait for driver eof ok
reached EOF, but the file may grow. delaying 1 second.
wait for driver eof timeout
wait for driver eof ok
FILEPUSH THREAD STOP

[pieterg]

that's still racy though, because it depends on when the data has made it all the way into the video/audio decoder.
But it does actually show us where the problem is; the EOF is not generated during pause, but immediately after it.

[betacentauri]

I have tested many things. One thing seems to work (but it's also not very nice):
I changed first seek in switchToTimeshift from m_cue->seekTo(0, -1000); to m_cue->seekTo(0, 0);
So it's a jump to start of timeshift file. Then filepush thread can read enough data to fill the decoders and no eof is thrown. This only works if timeshift file is not too small (several seconds depending on bitrate). The second seek from python part then seeks back to one second before end of file.

Filepush thread writes the data after every read (if data is available). So normally after first seek data should be available and so it should be written to PVR. Could there be an internal linux(or driver) buffer which buffers first the data before sending it to the decoders? Otherwise I don't know why PVR "sends" EOF even when we wrote data to PVR.
(it's very similar to the problem with the radio timeshift).