Timeshifting problems with OpenPLi 3.0
Re: Timeshifting problems with OpenPLi 3.0 #161
Re: Timeshifting problems with OpenPLi 3.0 #162
Re: Timeshifting problems with OpenPLi 3.0 #163
Re: Timeshifting problems with OpenPLi 3.0 #164
Re: Timeshifting problems with OpenPLi 3.0 #165
Posted 29 January 2013 - 23:06
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 to:143 if (m_stop) 144 break; 141 sendEvent(evtEOF); 145 if (m_stream_mode)
By the looks of it, that would break end-of-file detection (playback should stop when the file ends)
Or only sending EOF if eofcount=10.
that won't fix things on low-bandwidth channels, you'll easily get more than 10 EOF iterations before the buffer has grown to 188*1024 again, so you'd still get the EOF event.
Re: Timeshifting problems with OpenPLi 3.0 #166
Posted 29 January 2013 - 23:15
As I looked at the patch I got the impression that the eof detection was damaged by this.
Edited by Frenske, 30 January 2013 - 03:53.
English please. ;)
WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W
Re: Timeshifting problems with OpenPLi 3.0 #167
Posted 30 January 2013 - 18:27
However, to my big surprise, last week i tried an OE2.0 based image and found out that the timeshift works flawless here!
Sorry but this is the end of Openpli for me (unless issue's are fully resolved ).
Edited by Apple740, 30 January 2013 - 18:29.
Re: Timeshifting problems with OpenPLi 3.0 #168
Posted 30 January 2013 - 19:07
thanks for looking into it.
I made several tests:
1. Playing recording with skipping before start of file or after file end. And watching until normal end of file -> no problems
2. Normal live tv -> as expected no problems
3. Normal timeshift -> the problem is fixed
My fix "only" sends no EOF, if there was a stop/pause request. So end of file recognition works as before.
If there is a bigger timeshift buffer, then also no EOF event is sent while skipping.
You and everyone else with an ET9x00 can test it. I have attached the enigma2 binary.
Attached Files
Re: Timeshifting problems with OpenPLi 3.0 #169
Posted 31 January 2013 - 00:00
but there is a bug runs all the way with pli even pli2
this happen when you start timeshift a channel that included a dvb subs . I mean when resume play TShift the last sub choosed disappear and to get it back need press yellow button and choose it AGAIN.
hope you understand me.
BR
ET9000,DM500s+usbTTdvb-3600 ,DVB2000,Humax5400, MACbook PRO retina 13", MAC pro 2 x Quad XEON-2.8GB , 8GB ECC, 4TB+FusionDrive(SSD) , LG-24FHD, HD6870,Debian server
"Since the dawn of our species, Man has been blessed with curiosity"
Re: Timeshifting problems with OpenPLi 3.0 #170
Posted 31 January 2013 - 12:03
I would like to use your fix but I`m having a VU+Uno.
My build environement is setup and I was able to successfuly build my first OpenPLi image.
Could you please tell me how I can build only the enigma2 binary with the problematic commit reverted?
Many thanks in advance.
Re: Timeshifting problems with OpenPLi 3.0 #171
Posted 31 January 2013 - 23:16
@greatred: Here's the howto for my et9200. Your directories might be named in a different way.
1. Go to your build directory: <path_to_build_dir>/openpli-oe-core
2. Edit site.conf and put a # before last line:
#INHERIT += "rm_work"3. Change to <path_to_build_dir>/openpli-oe-core/build-et9x00 directory
4. Execute this
source env.source; bitbake -f -c compile -b ../meta-openpli/recipes-openpli/enigma2/enigma2.bb5. Enigma2 unpatched binary is now located in this directory:
<path_to_build_dir>/openpli-oe-core/build-et9x00/tmp/work/et9x00-oe-linux/enigma2-2.7+......./git/main
6. Edit this file: <path_to_build_dir>/openpli-oe-core/build-et9x00/tmp/work/et9x00-oe-linux/enigma2-2.7+......./git/lib/base/filepush.cpp
Goto line 141 and change
sendEvent(evtEOF); if (m_stop) break;into this
if (m_stop) break; sendEvent(evtEOF);And save file.
7. Change to <path_to_build_dir>/openpli-oe-core/build-et9x00 directory
8. Execute this
source env.source; bitbake -f -c compile -b ../meta-openpli/recipes-openpli/enigma2/enigma2.bb9. If there were no error messages, binary is located here: <path_to_build_dir>/openpli-oe-core/build-et9x00/tmp/work/et9x00-oe-linux/enigma2-2.7+......./git/main
Please check file date of the binary. It must have the date of the second compile!!
10. You can strip binary to make it smaller (I should be around 40MB. After stripping it's only 2,8MB big). You don't need to do this:
To strip execute this:
<path_to_build_dir>/openpli-oe-core/build-et9x00/tmp/sysroots/i686-linux/usr/bin/mips32el-oe-linux/mipsel-oe-linux-strip<space><path_to_enigma2_binary>11. Put the binary on your stb. E.g. in /tmp and do a chmod 755 enigma2
12. Do a init 4
13. Start enigma2 from /tmp with ./enigma2
Edited by betacentauri, 31 January 2013 - 23:17.
Re: Timeshifting problems with OpenPLi 3.0 #172
Posted 2 February 2013 - 21:50
seems that thanks to this @pieterg's commit:
http://openpli.git.s...5dab92ecab10ef7
vu last timeshit issues (an incorrect timeshif behavior on un-pausing /ie jump to 'live'/) should be fixed from the next build
//at least on my duo it's ok now ...
Re: Timeshifting problems with OpenPLi 3.0 #173
Re: Timeshifting problems with OpenPLi 3.0 #174
Posted 2 February 2013 - 22:57
assuming you have openpli oe core build enviroment set up:
1. clone (openpli) enigma2 repository
2. make your changes in there
3. bitbake enigma2 pointing to the recipe included in your local e2 repo, something like this:
brt@brt:~$ cd openpli-oe-core/build-vuduo/ brt@brt:~/openpli-oe-core/build-vuduo$ source env.source brt@brt:~/openpli-oe-core/build-vuduo$ bitbake -b ~/enigma2/enigma2.bbit will fail on do_package, but you'll find package content in ~/enigma2/build/package
(and of course on subsequent tests/builds you'll have to remember all these pull / reset / cleansstate etc...)
//and sorry for OT
Edited by blzr, 2 February 2013 - 22:58.
Re: Timeshifting problems with OpenPLi 3.0 #175
Posted 3 February 2013 - 00:19
I don't believe(but cannot exclude) that it fixes the problem with seeking back when you are almost at the end of the timeshift buffer (as described in this thread).
For this you should change the filepush.cpp
It would be great if you can test it.
@blzr: Thanks! That seems easier. My current problem was that everytime someone commited a patch a new folder was checked out and I had to move my changes to the new folder.
Re: Timeshifting problems with OpenPLi 3.0 #176
Re: Timeshifting problems with OpenPLi 3.0 #177
Re: Timeshifting problems with OpenPLi 3.0 #178
Posted 3 February 2013 - 12:58
@dima: black screen while seeking? I don't have that. I only had black screens when I started normal time shift. What Stb do you use? What do we have to do to reproduce your problem?
Re: Timeshifting problems with OpenPLi 3.0 #179
Posted 3 February 2013 - 13:19
action -> InfobarTimeshiftActivateActions timeshiftActivateEnd activateTimeshiftEnd play, ... decoder state: play, vpid=-1, apid=-1 DEMUX_STOP - pcr - ok DEMUX_STOP - video - ok VIDEO_STOP - ok AUDIO_STOP - ok DEMUX_STOP - audio - ok AUDIO_CONTINUE - ok cleaning up TuxTxt cache cleared alloc PVR allocate demux loading streaminfo for /media/hdd/timeshift/timeshift.aPMI3H setIoPrio best-effort level 0 ok FILEPUSH THREAD START ok ... now we start!! eventNewProgramInfo TS have 1 video stream(s) (0647), and 1 audio stream(s) (0a2f), and the pcr pid is 0647, and the text pid is ffffffff seeking relative to end. len=5527800, seek = -1000 samples step 41942988, pts begin 6850798943, pts end 6856326743, offs begin 51724, offs end 109346816: eDVBTSTools::getPTS got it from sc file offset=51724 pts=6850798943 adding sample 51724: pts 0 -> pos 51724 (diff 0 bytes) eDVBTSTools::getPTS got it from sc file offset=41987004 pts=6852865343 adding sample 41994712: pts 2066400 -> pos 41987004 (diff -7708 bytes) eDVBTSTools::getPTS got it from sc file offset=72085240 pts=6854483543 adding sample 83937700: pts 3684600 -> pos 72085240 (diff -11852460 bytes) using: 3684600:5527800 -> 72085240:109346816 eDVBTSTools::getPTS got it from sc file offset=72085240 pts=6854483543 adding sample 109326512: pts 3684600 -> pos 72085240 (diff -37241272 bytes) calculated diff -20468 ms diff to big, refining using: 3684600:5527800 -> 72085240:109346816 eDVBTSTools::getPTS got it from sc file offset=72085240 pts=6854483543 adding sample 109326512: pts 3684600 -> pos 72085240 (diff -37241272 bytes) calculated diff -20468 ms diff to big, refining using: 3684600:5527800 -> 72085240:109346816 eDVBTSTools::getPTS got it from sc file offset=72085240 pts=6854483543 adding sample 109326512: pts 3684600 -> pos 72085240 (diff -37241272 bytes) calculated diff -20468 ms diff to big, refining using: 3684600:5527800 -> 72085240:109346816 eDVBTSTools::getPTS got it from sc file offset=72085240 pts=6854483543 adding sample 109326512: pts 3684600 -> pos 72085240 (diff -37241272 bytes) calculated diff -20468 ms diff to big, refining using: 3684600:5527800 -> 72085240:109346816 eDVBTSTools::getPTS got it from sc file offset=72085240 pts=6854483543 adding sample 109326512: pts 3684600 -> pos 72085240 (diff -37241272 bytes) calculated diff -20468 ms TuxTxt cache cleared diff to big, refining aborting. Taking 109326512 as offset for 3684600 ok, resolved skip (rel: 0, diff 3684600), now at 068430b0 decoder state: play, vpid=1607, apid=2607 DMX_SET_PES_FILTER(0xa2f) - audio - ok DEMUX_START - audio - ok AUDIO_SET_BYPASS(1) - wait for driver eof ok reached EOF, but the file may grow. delaying 1 second. ok AUDIO_PAUSE - ok AUDIO_PLAY - ok Video Device: /dev/dvb/adapter0/video0 demux device: /dev/dvb/adapter0/demux6 VIDEO_SET_STREAMTYPE 1 - ok DMX_SET_PES_FILTER(0x647) - video - ok DEMUX_START - video - ok VIDEO_FREEZE - ok VIDEO_PLAY - ok VIDEO_SLOWMOTION(0) - ok VIDEO_FAST_FORWARD(0) - ok VIDEO_CONTINUE - ok AUDIO_CONTINUE - ok disable teletext subtitles eDVBServicePlay::switchToTimeshift, in pause mode now. eDVBServicePlay::pause decoder state: pause, vpid=1607, apid=2607 VIDEO_SLOWMOTION(0) - ok VIDEO_FAST_FORWARD(0) - ok VIDEO_FREEZE - ok AUDIO_PAUSE - ok have 1 video stream(s) (0647), and 1 audio stream(s) (0a2f), and the pcr pid is 0647, and the text pid is ffffffff decoder state: pause, vpid=1607, apid=2607 VIDEO_SLOWMOTION(0) - ok VIDEO_FAST_FORWARD(0) - ok VIDEO_FREEZE - ok AUDIO_PAUSE - ok resolved to PAUSE eDVBServicePlay::pause eDVBServicePlay::seekTo: jump -90000 seek. eFilePushThread stopping thread FILEPUSH THREAD STOP thread joined 0 AUDIO_CLEAR_BUFFER - ok VIDEO_CLEAR_BUFFER - ok setIoPrio best-effort level 0 ok FILEPUSH THREAD START seeking relative to end. len=5544000, seek = -90000 using: 3684600:5527800 -> 72085240:109346816 eDVBTSTools::getPTS got it from sc file offset=107839080 pts=6856256543 adding sample 107854848: pts 5457600 -> pos 107839080 (diff -15768 bytes) calculated diff 40 ms aborting. Taking 107854848 as offset for 5457600 ok, resolved skip (rel: 0, diff 5457600), now at 066dbc00 eDVBChannel: End of file! PATready use pmtpid 025f for service_id 025f eDVBChannel: pvrEvent evtStopped eventNewProgramInfo TS have 1 video stream(s) (0647), and 2 audio stream(s) (0a2f, 0e17), and the pcr pid is 0647, and the text pid is ffffffff decoder state: pause, vpid=1607, apid=2607 VIDEO_SLOWMOTION(0) - ok VIDEO_FAST_FORWARD(0) - ok VIDEO_FREEZE - ok AUDIO_PAUSE - ok resolved to FAST FORWARD eDVBServicePlay::setFastForward(-2) setting cue skipmode to -2 skipmode ratio is -180000:90000, bitrate is 14272223 bit/s resolved to: -951788 524288 flush pvr eFilePushThread stopping thread wait for driver eof aborted by signal FILEPUSH THREAD STOP thread joined 0 AUDIO_CLEAR_BUFFER - ok VIDEO_CLEAR_BUFFER - ok setIoPrio best-effort level 0 ok FILEPUSH THREAD START done decoder state: trickmode, vpid=1607, apid=2607 AUDIO_STOP - using: 5457600:5527800 -> 107839080:109346816 eDVBTSTools::getPTS got it from sc file offset=109319204 pts=6856326743 adding sample 37343289760: pts 5527800 -> pos 109319204 (diff -37233970556 bytes) calculated diff -19262309 ms diff to big, refining using: 5457600:5527800 -> 107839080:109319204 eDVBTSTools::getPTS got it from sc file offset=109319204 pts=6856326743 adding sample 36661376348: pts 5527800 -> pos 109319204 (diff -36552057144 bytes) calculated diff -19262309 ms diff to big, refining using: 5457600:5527800 -> 107839080:109319204 eDVBTSTools::getPTS got it from sc file offset=109319204 pts=6856326743 adding sample 36661376348: pts 5527800 -> pos 109319204 (diff -36552057144 bytes) calculated diff -19262309 ms diff to big, refining using: 5457600:5527800 -> 107839080:109319204 ok DEMUX_STOP - audio - eDVBTSTools::getPTS got it from sc file offset=109319204 pts=6856326743 ok AUDIO_CONTINUE - ok VIDEO_SLOWMOTION(0) - ok VIDEO_FAST_FORWARD(1) - ok VIDEO_CONTINUE - adding sample 36661376348: pts 5527800 -> pos 109319204 (diff -36552057144 bytes) calculated diff -19262309 ms diff to big, refining using: 5457600:5527800 -> 107839080:109319204 eDVBTSTools::getPTS got it from sc file offset=109319204 pts=6856326743 adding sample 36661376348: pts 5527800 -> pos 109319204 (diff -36552057144 bytes) calculated diff -19262309 ms diff to big, refining aborting. Taking 36661376348 as offset for 5527800 ok, resolved skip (rel: 1, diff 5527800), now at 88930355c ok eDVBChannel: End of file! eDVBChannel: pvrEvent evtStopped wait for driver eof ok reached EOF, but the file may grow. delaying 1 second. eDVBChannel: End of file! wait for driver eof ok reached EOF, but the file may grow. delaying 1 second. eDVBChannel: End of file! wait for driver eof ok reached EOF, but the file may grow. delaying 1 second. eDVBChannel: End of file! wait for driver eof ok reached EOF, but the file may grow. delaying 1 second. eDVBChannel: End of file! wait for driver eof ok reached EOF, but the file may grow. delaying 1 second. eDVBChannel: End of file! wait for driver eof ok reached EOF, but the file may grow. delaying 1 second. eDVBChannel: End of file! wait for driver eof ok reached EOF, but the file may grow. delaying 1 second. eDVBChannel: End of file! wait for driver eof ok reached EOF, but the file may grow. delaying 1 second. eDVBChannel: End of file! wait for driver eof ok reached EOF, but the file may grow. delaying 1 second. eDVBChannel: End of file! wait for driver eof ok FILEPUSH THREAD STOP eDVBChannel: End of file! eDVBChannel: pvrEvent evtStopped 4416
GigaBlue UHD Quad 4K /Lunix3-4K/Duo 4K
Re: Timeshifting problems with OpenPLi 3.0 #180
Posted 3 February 2013 - 15:27
I made several tests:
1. Playing recording with skipping before start of file or after file end. And watching until normal end of file -> no problems
2. Normal live tv -> as expected no problems
3. Normal timeshift -> the problem is fixed
My fix "only" sends no EOF, if there was a stop/pause request. So end of file recognition works as before.
If there is a bigger timeshift buffer, then also no EOF event is sent while skipping.
I've taken a closer look at the evtEOF handling in filepush, and indeed when we avoid emitting evtEOF when the thread is stopping (thus ignoring the decoder being empty, which it is because of the skip attempt), avoids that the timeshift switches to the live point.
And as far as I can see there are no side effects.
Only one thing is remaining, as Dima73 points out, sometimes you cannot rewind from the live point, you'll get a black screen.
In that case, the only way to get away from the live point, is press pause, and wait a few seconds.
8 user(s) are reading this topic
0 members, 8 guests, 0 anonymous users