View Full Version : [Mut@nt HD2400] Software crash when fast forward a recording
As the title say the box crashes soon as I fast forward my recordings
As the title say the box crashes soon as I fast forward my recordings
So crash logs?
I found one in the box but how to I pass it to here ?
Sent from my TIMEBOMB!!!
I manage to send it to my email and to the support I think , if someone could confirm it please
Can't copy paste to here as it says it's to long . If there is another way of posting the log here can someone help me . Thanks
Sent from my TIMEBOMB!!!
Put the log in a zip file and upload it here.
Also please post a step-by-step of how to provoke your crash including the location of the recording.
ok i try and describe how it happens.
press PVR on the remote , choose the file i want to watch from my recording , and when fastforward or reverse it crashes, i get a frozen screen with a spin blue circle on the left and corner
the locatioin of my recording is
/media/hdd/movie/
46698
DaMacFunkin
05-02-16, 17:47
Which skin are you using?
Just swapped skins to the vix-night-hd and it crashed as well when fast forward
That log does not correspond to your crash.
What plugins do you have loaded?
Please start with a fresh flash. DOn't restore any plugins and see if you still have the same problem.
The only plug in I have installed is the blue hd
This is a fresh flash 036 done 2 days ago
In the plug in menu I only have
CrossEPg downloader
Media scanner
Multi-transcoding setup
OpenWebif
Picture player
Sent from my TIMEBOMB!!!
That has to be the log because I checked before replicating the crash and there was no logs , and after the crash that log was the only available
Logs are normally saved in /home/root/logs (I think) and have a filename ending in .log
Did you install BlueHD directly from feeds or from elsewhere (or did you later apply any modification files)?
Installed direct from feeds . The log file I sent to my email and it came with that format when I pressed send on the box it sent to the support and a copy to my email as it says on the setting under the log menu
Sent from my TIMEBOMB!!!
What you are describing is not a crash, it is an endless spinner.
That log you posted is of someone browsing the log manager. No crash or endless spinner at the end of that file.
Probably I didn't describe correctly .
After you press fast forward , you get the blue spinner on the top right corner and doesn't go away and you can't to nothing on the box , it just freezes with the spinner on . The only way I can get it back to work is power off from the back of the box and power back on .
Sent from my TIMEBOMB!!!
i have had this from time to time also but on a duo 2 (cable vm) with openvix and its done it once again on a fresh install of 3.2.036 so far was also manual setup so no backup settings carried across
its not a crash so there is never a log file it just freezes the box with a spinner only way to get out of it is powering it down from the rear
i only have image plug ins installed and at present time with 3.2.036 the bello skin and mgcamd 1.38 and same default directory (movie)
the weird thing is it only ever happens on some recordings on channel 5 (sd)
very unlikely but i have just changed the recordings from sd to HD on channel 5 to see if it makes a difference yet to test tho
i even swapped out my internal HDD just to make sure it wasnt an issue with that but happened on both HDD i installed
1 thing i have noticed not sure if its just me tho is when either FF or RW on 8X it looks jumpy and slower than 4X and not as smooth as all the other speeds this maybe just me and may not even relate to the issue but i swear it looks odd
hope this helps
My recordings are from 30.0w
It's good to know I'm not the only one getting this problem . Maybe it's a glitch
Sent from my TIMEBOMB!!!
Turn on debug logs and reproduce
My recordings are from 30.0w
It's good to know I'm not the only one getting this problem . Maybe it's a glitch
Sent from my TIMEBOMB!!!
This is what I mean about a step-by-step. We are at post 18 and it it the first time you mention anything about 30W. If you can't supply the complete information that leads to this problem and a debug log that corresponds to it, it is very inlikely it will ever be lokked at.
I'm sorry if I didn't mention 30w didn't think that the satellite I watch would have anything to do with fast forward or reversing a recording ...
Like I said above I cleared all the logs , replicated and that is what came up I will do it again in a moment see what log will come up now
Sent from my TIMEBOMB!!!
ok so i tried again , and going to explain the best i can
recording from 30.0W
cleared all logs and debugs from the log menu so this section is clear
tested x2 forward no problem
tested x4 forward no problem
tested x8 forward and the blue spinner came up on the top left corner of the screen , left it for about 5min screen was frozen so had to power of the box and restart it
check the Log / debug there was one there now sent it and received a copy on my email wich i will enclose here on the screen said to quote the 1454752640.15
46707
Can I clarify, do you mean that you were playing back a previously recorded programme after it had recorded (ie no other recording was happening at that time of crash), or were you playing back something that you were still recording?
I tried several previously recorded programmes (and no other recording was happening) from my solo2 (I use 28.2E) and couldn't re-create this and I tested forward at x128.
Does this problem on all previously recorded material or a certain one?
This was a recording from last night . And nothing was recording when I was testing it this morning
It only started to happen since the 035 build
Sent from my TIMEBOMB!!!
Ok, thanks. Does it happen to all your recordings then or certain ones (ie could there be a pattern to type of recording like SD or HD, etc)?
This was a hd channel recording and it has happen on sd as well on 30.0w
I can test on sky as well if that helps
Sent from my TIMEBOMB!!!
ok so i tried again , and going to explain the best i can
recording from 30.0W
cleared all logs and debugs from the log menu so this section is clear
tested x2 forward no problem
tested x4 forward no problem
tested x8 forward and the blue spinner came up on the top left corner of the screen , left it for about 5min screen was frozen so had to power of the box and restart it
check the Log / debug there was one there now sent it and received a copy on my email wich i will enclose here on the screen said to quote the 1454752640.15
46707
you saying that issue is on 8X i have noticed 8X seems jumpy and weird could this be related TBH i never noted when the crashes happened to me what speed it was on think i will take a note on it also when FF at 8X is the crash instant or after a few seconds / mins?
Why does the log not have the correct name?
You need to FTP to the box and retrieve the log as soon as the endless spinner appears.
What is happening is you are leaving the endless spinner running and it is creating an enormous log which is removed on reboot.
Why does the log not have the correct name?
You need to FTP to the box and retrieve the log as soon as the endless spinner appears.
What is happening is you are leaving the endless spinner running and it is creating an enormous log which is removed on reboot.
i will try to recreate it and grab a log
took a while but managed to make it happen hope this helps
Just found another log file not sure it will help pretty sure it was from before on another crash due to FF/RW
you saying that issue is on 8X i have noticed 8X seems jumpy and weird could this be related TBH i never noted when the crashes happened to me what speed it was on think i will take a note on it also when FF at 8X is the crash instant or after a few seconds / mins?
Takes about 2 to 4 seconds and you get the blue spinner and image freezes
Why does the log not have the correct name?
You need to FTP to the box and retrieve the log as soon as the endless spinner appears.
What is happening is you are leaving the endless spinner running and it is creating an enormous log which is removed on reboot.
No idea why it doesn't display the correct name, on log menu setting I put my email and user name , I press send and it send the report and a copy to my email, I download it and attach here .
I have no idea how to ftp , I'm still learning .... Sorry
I've noticed (for months) that when I increase from x4 to x8 the speed appears to drop to x1 for a second or so before x8 kicks in.
i will try to recreate it and grab a log
took a while but managed to make it happen hope this helps
Any news on this ?
Fast forward x4 is painful lol
Andy_Hazza
07-02-16, 11:26
No issues here with 28.2. I have recorded various programs, both fta and sky premium channels and works up to 128x with no issues. I use Oscam latest on my receivers.
Sent from my iPhone using Tapatalk
I recorded some on 28.2 hd and sd will test them in a bit
Sent from my TIMEBOMB!!!
I'm using cccam 2.3.0
Sent from my TIMEBOMB!!!
Ok so I tested 28.2 hd and sd recording and no crash up to 128x
Only getting crashes on 30.0w
Sent from my TIMEBOMB!!!
Any news from the support team about this issue ?
Ok so I tested 28.2 hd and sd recording and no crash up to 128x
Only getting crashes on 30.0wI'm confused by the logs then, which show the box using Virgin cable rather than a satellite. Is this normal?
< 35.736495> [eDVBFrontend] setSlotInfo for dvb frontend 0 to slotid 0, descr Vuplus DVB-C NIM(TT3L10), need rotorworkaround No, enabled Yes, DVB-S2 No
....
< 36.645175> [eDVBDB] loading bouquet... /etc/enigma2//userbouquet.abm.cable_uk_virgin.main.tv
There are also no signs of crashes - only possible lock-ups (which is not the same thing at all).
That doesn't sound right i don't use Virgin cable , all my 4 tuners as satellite
Sent from my TIMEBOMB!!!
That doesn't sound right i don't use Virgin cable , all my 4 tuners as satelliteSorry =- I was somehow looking at baz2001uk's log.
The log you posted seems to be the one from when you sent the log via mail, so it's not the log from when you had the problem (which would be the previous one).
I will try a do a new log tomorrow and send it again to the support , I will clear all the logs and the replicate the freeze spinner , only happens on the 30.0w above 8x speed 2x and 4x work fine that's what I been using last few days .
I also tested on the 28.1 hd and sd and it works fine fast forward up to 128x it seems it only happens on the 30.0w
Witch I find strange why would just freeze on one satellite and not booth
Sent from my TIMEBOMB!!!
It's best to enable debug, restart box and fast forward and after it crashes check in /home/root/logs and you will have one (or more) files ending in .log.
Attach this actual .log file rather than email to support.
Sorry =- I was somehow looking at baz2001uk's log.
The log you posted seems to be the one from when you sent the log via mail, so it's not the log from when you had the problem (which would be the previous one).
My bad i put my debug log up in aid to help as i get the same issue but very rare on my duo2 with VM (wasnt sure if it would be of any help being a different box and connection)
if it helps out i am happy to start a fresh thread
I get something similar if I fast forward or rewind when playing a film from my CIFS connected NAS but only if I press say the 1 or 3 button multiple times in a row. If I press and then wait for the film to catch up then press again then no issues. When the film freezes I can press stop which brings me back to the media player screen.
sorry to pull up an old thread but a slight update on my issue as OP but on a duo 2 after changing the recordings from channel 5 to channel 5HD the issue has now gone i have not made any changes to the system since
find it strange the issue is due to SD / HD But the problem has gone i dont know how that can fix the problem maybe my receiver just dont like channel 5 lol
I given up with this , there is bug somewhere that's for sure . It's at least 3 or 4 ppl with this issue on this post .
Sent from my TIMEBOMB!!!
I given up with this , there is bug somewhere that's for sure . It's at least 3 or 4 ppl with this issue on this post .
Sent from my TIMEBOMB!!!
is the record on sd or HD ? might be worth switching to the other as dont know how but its done the trick for me so fat touch wood
is the record on sd or HD ? might be worth switching to the other as dont know how but its done the trick for me so fat touch woodWell, the only logs here that show hangs (there are no crashes...) are two from baz2011uk (Enigma2-2016-02-06_13-20-50.log in post #29 and Untitled attachment 00004.txt in post #30) which contain things like this:
< 677.353151> [eTSMPEGDecoder] decoder state: trickmode, vpid=044d, apid=0457and on Freeview an SD recording would be an mpeg2 video, whereas an HD one would be an h.264 (mp4) one. Perhaps satellite brodcasts have the same difference?
Oh - and just before the spinner is noted as being displayed, this gets reported:
< 707.621070> [eDVBChannel] frame skipping failed, reverting to byte-skipping
< 707.622698> [eDVBChannel] we are at 113431304, and we try to find the iframe here:
Oh - and just before the spinner is noted as being displayed, this gets reported:
< 707.621070> [eDVBChannel] frame skipping failed, reverting to byte-skipping
< 707.622698> [eDVBChannel] we are at 113431304, and we try to find the iframe here:
So a quick guess would be that the code inside the locking here doesn't return:
m_tstools_lock.lock();
int r = m_tstools.findFrame(iframe_start, iframe_len, direction);
m_tstools_lock.unlock();(that's dvb.cpp:1781).
The findFrame() is in tstools.cpp. It does contain some mpeg2-specific code (see previous 2 posts) and some loops - perhaps one of them can go on forever...
is the record on sd or HD ? might be worth switching to the other as dont know how but its done the trick for me so fat touch wood
I tried booth hd and sd and booth get stuck with the spinner just going around on top left corner . This is in 30.0
The 28. Works fine hd and sd recording I can fast forward to the max and never gets stuck
Sent from my TIMEBOMB!!!
I've just gone all the way through a 1 hour mpeg2 and a 2.5 hour h.264 video at 32x. No problems seen.
The mpeg2 one showed:
< 500.812735> [eDVBChannel] frame skipping failed, reverting to byte-skipping
< 500.812809> [eDVBChannel] we are at 1447234340, and we try to find the iframe here:
< 500.813500> [eMPEGStreamInformation] index 109824 is past EOF
< 500.813624> [eMPEGStreamInformation] getStructureEntryNext failed, no data
< 500.813686> [eDVBChannel] failed
and similar sequence shortly after as it checked for the file growing (could be an active recording)
and the h.264 one gave:
< 1180.708220> [eDVBChannel] frame skipping failed, reverting to byte-skipping
< 1180.708283> [eDVBChannel] we are at 5546220524, and we try to find the iframe here:
< 1180.708863> [eDVBChannel] failed
< 1180.797585> [eDVBVideo0] VIDEO_GET_EVENT PROGRESSIVE_CHANGED 1
< 1180.960041> [eFilePushThread] wait for driver eof timeout
followed by two more similar sequences.
I also ran both files backwards at 32x (since teh log in post #29 is going backwards) and both run OK, reporting:
< 2316.576585> [eDVBChannel] pvrEvent evtStopped
< 2341.698094> [eDVBChannel] reached SOF
< 2341.698454> [eDVBChannel] SOF
for the mpeg2 stream and
< 2588.268239> [eMPEGStreamInformation] getStructureEntryNext before start-of-file
< 2588.268398> [eDVBChannel] frame skipping failed, reverting to byte-skipping
< 2588.268477> [eDVBChannel] we are at 479212, and we try to find the iframe here:
< 2588.268613> [eMPEGStreamInformation] getStructureEntryNext before start-of-file
< 2588.268676> [eDVBChannel] failed
< 2588.268741> [eDVBChannel] reached SOF
< 2588.268954> [eDVBChannel] SOF
for the h.264 one when they reached the start of the recording.
So, no issues.
Is this hang reproducible (in that it always happens for a particular file)?
If so, can you upload that file (and all associated meta files) to Dropbox/OneDrive/GoogleDrive or similar so that others can have a look at it and see whether it happens for them too?
I've just gone all the way through a 1 hour mpeg2 and a 2.5 hour h.264 video at 32x. No problems seen....Was this from a recording on sat 28.2 or sat 30w as OP said recording/playback at any speed is okay on 28.2 but doesn't appear to be on 30w!!
Could this be an issue with dvb driver/GST not liking something in data stream of recording on 30oW but it's okay with $ky 28.2 because if it is only re-creatable with recording from a specific satellite then that could imply a problematic data stream maybe?
Just a thought :)
I've just gone all the way through a 1 hour mpeg2 and a 2.5 hour h.264 video at 32x. No problems seen.
The mpeg2 one showed:
and similar sequence shortly after as it checked for the file growing (could be an active recording)
and the h.264 one gave:
followed by two more similar sequences.
I also ran both files backwards at 32x (since teh log in post #29 is going backwards) and both run OK, reporting:
for the mpeg2 stream and
for the h.264 one when they reached the start of the recording.
So, no issues.
Is this hang reproducible (in that it always happens for a particular file)?
If so, can you upload that file (and all associated meta files) to Dropbox/OneDrive/GoogleDrive or similar so that others can have a look at it and see whether it happens for them too?
the only thing i can get it to repeat the same spinner is when home and away is recorded on sd channel 5 this is the only channel and only programme it dose it on i have been recording it in HD for a while now but happy to do a few in sd and see if i can still get the spinner and then upload the file after (before you ask its not me watching that crap lol)
Was this from a recording on sat 28.2 or sat 30w as OP said recording/playback at any speed is okay on 28.2 but doesn't appear to be on 30w!!Since I don't have any satellite tuner, no. I was just testing generically.
Thinking more about what my logs show compared to the spinning ones, it's actually getting "lost" in mid-stream.
So I was also wondering whether there was something "wrong" with the offending stream, such as did the picture break up in places when played at normal speed.
..but happy to do a few in sd and see if i can still get the spinner and then upload the file after (before you ask its not me watching that crap lol)If you could do that I'd be happy to take a look at it to see whether I can find anything.
I promise not to actually watch it, and on fast-forward/back I won't hear it either.
If you could do that I'd be happy to take a look at it to see whether I can find anything.
I promise not to actually watch it, and on fast-forward/back I won't hear it either.
lol i will set up a recording this week and drop you a PM with a link to grab the files(s) do you need just the media .ts file or all the other files that are generated with it? i trust you not to watch the content tho as you may be shocked and scared for life
i blamed the wife saying t was just her ding it but i managed to make it do it but to be fair it was by force going FF and RW a few times
lol i will set up a recording this week and drop you a PM with a link to grab the files(s) do you need just the media .ts file or all the other files that are generated with it?If you could send the other files as well that would be useful, thanks.
If you could send the other files as well that would be useful, thanks.
no probs
did you want me to get the spinner up also and also send debug logs at same time?
no probs
did you want me to get the spinner up also and also send debug logs at same time?Yes please, so I can see where file the file it reports the problem.
Yes please, so I can see where file the file it reports the problem.
Just dropped you a PM birdman
Well, I've been sent an "offending" recording, run through it backwards at 16x(twice) and 8x, and all hung.
So something to work on....
One thing I did note was that the spinner doesn't get cleared when I run init 4/init 3 to restart enigma2. Does anyone know of any way to clear whatever is doing this other then a full reboot?
@birdman On Saturday I was watching a recording from 30.0 and by mistake went above 4x and the spinner got stuck as usual , I left it for about 1h to see if it would stop and go back to normal tv but it didn't I had to power off the box and back on
Sent from my TIMEBOMB!!!
One thing I did note was that the spinner doesn't get cleared when I run init 4/init 3 to restart enigma2. Does anyone know of any way to clear whatever is doing this other then a full reboot?;) . .
http://forums.openpli.org/topic/40837-impossible-to-exit-endless-spinner-with-init-4
;) . .
http://forums.openpli.org/topic/40837-impossible-to-exit-endless-spinner-with-init-4That's what C++ destructors are for.
Well, I suppose I'll find out shortly....
That's what C++ destructors are for.
Well, I suppose I'll find out shortly....Well. By adding a call to disableSpinner() (in gDC::~gDC()) I got rid of the spinner. Or rather, I got it to stop on init 4, then it started performing "as normal" as init 3 started up enigma2 again.
BUT - it also managed to totally remove the actual picture (and the showiframe background image). Menus worked OK, but no picture.
All cleared by rebooting, but that's what I'm trying to avoid.
In the meantime I did find that the looping recording keeps going through the is_mpeg2 block in eDVBTSTools::findFrame(). It does exit it each time, so the loop problem is somewhere else.
That sounds complicated lol
Sent from my TIMEBOMB!!!
Well, I can now see what is happening. When looking for a suitable(?) Iframe it sometimes moves forwards (when it is running backwards overall).
And it can get to the state where it does neither:
< 13850.296874> [GML: eDVBTSTools::findNextPicture] findFrame() new_offset: 80553699 new_len: 91363 dir: -13
< 13850.301578> [GML: eDVBTSTools::findFrame] is_mpeg2 end - nr_frames: 0
< 13850.301747> [GML: eDVBTSTools::findNextPicture] findFrame() new_offset: 81003741 new_len: 47406 dir: 0
< 13850.301845> [GML: eDVBTSTools::findFrame] is_mpeg2 end - nr_frames: 13
< 13850.301909> [GML: eDVBTSTools::findNextPicture] findFrame() new_offset: 80553699 new_len: 91363 dir: -13
< 13850.302112> [GML: eDVBTSTools::findFrame] is_mpeg2 end - nr_frames: 8
< 13850.302188> [GML: eDVBTSTools::findNextPicture] findFrame() new_offset: 80329979 new_len: 53204 dir: -8
< 13850.305704> [GML: eDVBTSTools::findFrame] is_mpeg2 end - nr_frames: 0
< 13850.305860> [GML: eDVBTSTools::findNextPicture] findFrame() new_offset: 80330137 new_len: 53046 dir: 0
< 13850.305946> [GML: eDVBTSTools::findFrame] is_mpeg2 end - nr_frames: 0
< 13850.306109> [GML: eDVBTSTools::findNextPicture] findFrame() new_offset: 80330129 new_len: 8 dir: 0
< 13850.306198> [GML: eDVBTSTools::findFrame] is_mpeg2 end - nr_frames: 0
< 13850.306260> [GML: eDVBTSTools::findNextPicture] findFrame() new_offset: 80330129 new_len: 8 dir: 0
< 13850.306337> [GML: eDVBTSTools::findFrame] is_mpeg2 end - nr_frames: 0
...ad infinitum...
However, there is more to it than that, as this sequence occurred earlier:
< 13842.431813> [GML: eDVBTSTools::findFrame] is_mpeg2 end - nr_frames: 19
< 13842.431891> [GML: eDVBTSTools::findNextPicture] findFrame() new_offset: 393154835 new_len: 56959 dir: -19
< 13842.447405> [GML: eDVBTSTools::findFrame] is_mpeg2 end - nr_frames: 0
< 13842.447580> [GML: eDVBTSTools::findNextPicture] findFrame() new_offset: 393489633 new_len: 67334 dir: 0
< 13842.447694> [GML: eDVBTSTools::findFrame] is_mpeg2 end - nr_frames: 19
< 13842.447763> [GML: eDVBTSTools::findNextPicture] findFrame() new_offset: 393154835 new_len: 56959 dir: -19
< 13842.447859> [GML: eDVBTSTools::findFrame] is_mpeg2 end - nr_frames: 10
< 13842.447930> [GML: eDVBTSTools::findNextPicture] findFrame() new_offset: 392917579 new_len: 67675 dir: -10
< 13842.454324> [GML: eDVBTSTools::findFrame] is_mpeg2 end - nr_frames: 0
< 13842.454804> [GML: eDVBTSTools::findNextPicture] findFrame() new_offset: 392917737 new_len: 67517 dir: 0
< 13842.454946> [GML: eDVBTSTools::findFrame] is_mpeg2 end - nr_frames: 10
< 13842.455414> [GML: eDVBTSTools::findNextPicture] findFrame() new_offset: 392728639 new_len: 59403 dir: -10and it somehow handled getting to 393154835 twice....
Think the current unstable gstreamer build included in release builds is borked for media, not recorded shows.
Too many similar issues on multiple manufacturers boxes here too, no matter the encoding.
Making progress.
I've found out (roughly) what the structure of an MPEG-2 TS file looks like and added various other debug statements to work with that.
Then discovered that the positioning is actually done with the help of the ts.sc (and ts.ap?) files, so I've found out what they look like (and have scripts to print out the info). They both look OK, so hopefully I can now find out why the code loops when looking for the "next" frame to display.
Mind you, as I work on this I do start to wonder how it actually does do 2x, 4x etc., as you can't just skip frames.- since most of them depend on you knowing what the previous/next one looked like it still has to calculate them. I also have no idea whether any of this is done in hardware - hopefully I don't need to know this in order to find the bug.
Any idea why it just happens to recording from 30 degrees whereas 28.2 degrees is fine?
Great work . Even if I didn't understand half of it cause I don't know much about programming lol
Hope you can get this fixed because fast forward at x4 is painful lol
Sent from my TIMEBOMB!!!
I posted ages ago in this thread, and now that real progress is being made it might be worth repeating....
For me, x2 and x4 start straight away. When I go to x8, the picture goes back to x1 for about 3 seconds before x8 kicks in.
Any idea why it just happens to recording from 30 degrees whereas 28.2 degrees is fine?Just guessing, but probably because one is an MPEG-2 stream and the other an H.264. These do have different start code structures and the mpeg one goes through additional frame-finding code (which is where I suspect the issue is).
Hope you can get this fixed because fast forward at x4 is painful lolYou could always use 3,6,9 (forward) and 1,4,7 (backwards) to skip instead.
Making progress.
I've found out (roughly) what the structure of an MPEG-2 TS file looks like and added various other debug statements to work with that.
Then discovered that the positioning is actually done with the help of the ts.sc (and ts.ap?) files, so I've found out what they look like (and have scripts to print out the info). They both look OK, so hopefully I can now find out why the code loops when looking for the "next" frame to display.
Mind you, as I work on this I do start to wonder how it actually does do 2x, 4x etc., as you can't just skip frames.- since most of them depend on you knowing what the previous/next one looked like it still has to calculate them. I also have no idea whether any of this is done in hardware - hopefully I don't need to know this in order to find the bug.
fair play mate as its all well over my head glad the files i did are helping to find out where the issue may lie and thank you for taking your own time to look into this :)
I can see the problem. Both in the file structure and in the enigma2 code.
The file is an MPEG2-TS stream, with mpeg2 video (and some audio stream - which don't come into play). Such a file is a series of 188 byte packet. Packets contain headers which say what they are (or, if they are the data part of the video, which stream - PID - they belong to).
mpeg2 stream have 3 sort of video-frames I-, which are "stand-alone", P- which contain just contain the differences from an earlier frame and B-, which contain differences from earlier and later frames. So to play a stream you need to start at an I-frame. This is what the enigma2 code is looking for.
But it does it in a truly Byzantine manner. Despite having a an ordered list of the location of all the I-, P-, and B- frame headers it seeks backwards and forward through this list counting how many frames it has skipped over (and includes sequence header and group frames in the count when it probably shouldn't - depends on what nr_frames is counting, which isn't clear at all).
And then along comes a file with a group of pictures which just contains an I-frame - nothing else (something IBBPBBPBB is more usual). So if the fast-backwards gets to the I-frame after this, the code start where it is, goes to the previous frame (the single I-frame), goes forward from there to the next frame. It is now back where it started. It returns this info and the frame gets displayed (presumably). The file offset is now back at the the original I-frame and we just get stuck in that one position.
I have implemented a fix such that if findFrame() finds it has got back to where it started (or beyond) it goes through the code again, but this time with the offset of the earlier I-frame it found. A terrible kludge (it uses a goto to jump backwards...), but it's no worse than the rest of the code in that area. And it does work (at least for that Home&Away recording).
I have a distinct feeling that the code could be re-written to be much simpler and cleaner.
One thing I did note was that the spinner doesn't get cleared when I run init 4/init 3 to restart enigma2. Does anyone know of any way to clear whatever is doing this other then a full reboot?
;) . .
http://forums.openpli.org/topic/40837-impossible-to-exit-endless-spinner-with-init-4My attempts to disable the spinner if enigma2 is "killed" work OK (call disableSpinner() in gRC::~gRC()).. HOWEVER, this just leaves things in a state where the TV picture doesn't display when enigma2 is restarted!! (menus etc. show up OK).
I noticed this in the log when it happens:
< 521.045359> [eDVBVideo0] VIDEO_PLAY failed: Operation not permitted
so presumably something isn't shutting down the device properly when enigma2 is killed?
I'm still looking at the FF/FR code (with the object of tidying it up).
In the process I have found what might actually be the cause of the original issue.
The problem is that findFrame() calls getStructureEntryNext(offset, ....) to get the next frame (so that it can get a length for the current one). THEN, if we have an mpeg, it calls getStructureEntryFirst(start, ....), the object here being to roll back start to the preceding sequence header. BUT, these two routines share an index into the cache file, so in fact the second call actually works back from offset, rather than from start (which is what it really intends to do).
It's possible that correcting this (which is possible) would fix the rewind hang. I'll need to test. At the moment my attempt at tidying up the code seems to have found a bug in the binary chop code in getStructureEntryNext(), so I'm checking that out too.
My attempts to disable the spinner if enigma2 is "killed" work OK (call disableSpinner() in gRC::~gRC()).. HOWEVER, this just leaves things in a state where the TV picture doesn't display when enigma2 is restarted!! (menus etc. show up OK).
I noticed this in the log when it happens:
< 521.045359> [eDVBVideo0] VIDEO_PLAY failed: Operation not permitted
so presumably something isn't shutting down the device properly when enigma2 is killed?
As previously posted Openpli are also discussing this and looking at how to terminate Enigma.... .. I think betacentauri is going to/has written some code
The problem is that findFrame() calls getStructureEntryNext(offset, ....) to get the next frame (so that it can get a length for the current one). THEN, if we have an mpeg, it calls getStructureEntryFirst(start, ....), the object here being to roll back start to the preceding sequence header. BUT, these two routines share an index into the cache file, so in fact the second call actually works back from offset, rather than from start (which is what it really intends to do).
It's possible that correcting this (which is possible) would fix the rewind hang.It does!!
At the moment my attempt at tidying up the code seems to have found a bug in the binary chop code in getStructureEntryNext(), so I'm checking that out too.Still working on that bit, but it does look like a problem (although I'd have expected it to have been encountered more often, so .....)
Still working on that bit, but it does look like a problem (although I'd have expected it to have been encountered more often, so .....)I've tracked that down now too. The binary search is written with low + extent, but on the index adjustment thinks it is running with low and high (so there's an off-by-one bug).
Patches later (soon) once I've tidied everything up and done some final testing.
I've tracked that down now too. The binary search is written with low + extent, but on the index adjustment thinks it is running with low and high (so there's an off-by-one bug).
Patches later (soon) once I've tidied everything up and done some final testing.
Congrats, now about the next 100 bugs :)
Fix
Patches later (soon) once I've tidied everything up and done some final testing.
Here they are:
47436
Whereas I can see how these would make fast-rewind hang (and could reproduce it...) I'm not so sure about fast-forward (which is simpler to code and less likely to end up in a loop). The only log in the thread is for a fast-rewind hang.
The patches are small, so here's the text.
--- tstools.cpp.orig 2016-03-22 15:53:35.531238005 +0000
+++ tstools.cpp 2016-03-22 16:14:31.033506752 +0000
@@ -860,6 +860,14 @@
if (is_mpeg2)
{
+// First we have to get back to where we were when we set start above
+// getStructureEntryNext has a private variable to remember where it was at the
+// end of the last call, and getStructureEntryFirst will set this correctly
+ if (m_streaminfo.getStructureEntryFirst(start, longdata) != 0)
+ {
+ eDebug("[eDVBTSTools] findFrame getStructureEntryFirst for is_mpeg2 failed");
+ return -1;
+ }
// Seek back to sequence start (appears to be needed for e.g. a few TCM streams)
while (nr_frames)
{
--- pvrparse.cpp.orig 2016-03-07 17:33:55.792854000 +0000
+++ pvrparse.cpp 2016-03-22 16:03:40.853748710 +0000
@@ -413,7 +413,8 @@
while (count > (structure_cache_size/4))
{
int step = count >> 1;
- ::lseek(m_structure_read_fd, (i + step) * entry_size, SEEK_SET);
+// Read entry at top end of current range (== i+step-1)
+ ::lseek(m_structure_read_fd, (i + step - 1) * entry_size, SEEK_SET);
unsigned long long d;
if (::read(m_structure_read_fd, &d, sizeof(d)) < (ssize_t)sizeof(d))
{
@@ -423,9 +424,12 @@
d = be64toh(d);
if (d < (unsigned long long)offset)
{
- i += step + 1;
- count -= step + 1;
+// Move start of range to *be* the last test (+1 more may be too high!!)
+// and remove tested count
+ i += step;
+ count -= step;
} else
+// Keep start of range but change range to that below test
count = step;
}
//eDebug("[eMPEGStreamInformation] getStructureEntryFirst i=%d size=%d count=%d", i, l, count);
Whereas I can see how these would make fast-rewind hang (and could reproduce it...) I'm not so sure about fast-forwardI suppose I should have tried it...so I just have on that Home and Away test file. It hangs going forwards too (on an unpatched image)....
Rob van der Does
22-03-16, 18:26
Did you check on PLi? They recently seem to have fixed a (very) fast forward issue (even up to 128 times for TS).
Did you check on PLi? They recently seem to have fixed a (very) fast forward issue (even up to 128 times for TS).No, I didn't. The code is quite convoluted in what it is doing, and anything that looks at all different would be a nightmare to compare.
The OpenPLi diff for what they did might be be useful, though.
From what I can see, the fix to make the file go back to the correct (earlier) spot when going backwards results in it creating a loop when going forwards. The code to do it all is split over 3 routines, which is where the problems lie - there is no useful interaction between their states.
I also have versions of findFrame() and findNextPicture() which I've changed a lot to simplify the logic. These seem to work OK (at least in a few tests I've just done) in both directions. Although 64x forward is "slower" than 16x forward.
birdman if i can be of any help please let me know i know i dont understand 99% of this but am willing to learn and help
birdman if i can be of any help please let me know i know i dont understand 99% of this but am willing to learn and helpThanks, but what I really need to know is how the incoming offset is being set, and what are valid and useful settings to return.
Thanks, but what I really need to know is how the incoming offset is being set, and what are valid and useful settings to return.
see lost me already
see lost me alreadyBut the post had its uses.
It's made me think that I ought to look at where the incoming value of the offset is coming from - so I might find out what has happened to get it there....
Given that the files in question haven't change in 4.0* I'll start working on that version now...
* well, tstools.cpp did. Two instances of hex constants on one line were lower-cased - there was a third on the same line which is still in upper-case(?!?).
At least it's not mixed case. :D
Given that the files in question haven't change in 4.0* I'll start working on that version now...Which I'll start by writing a findFrame() which goes to the I-frame in the previous or next GOP, return a valid frame-move count and let the caller decide what to do. The present code isn't guranteed to get out the the current GOP.
PS: I'd remove the big Fix tag from pos #85 if I could. Although the pvrparse.cpp path there is definitely correct and required. I have a test program to show that - it's not dependent on actually playing a movie file to test it.
Will be delayed .
At the moment I can't set-up a development environment on a Debian mips system.
There are lots of unresolved symbols when loading enigma2, ad I can't tell whether this is from the switch to gcc5.3 or just something I've missed in the environment. (Since all of the OpenVix libraries get stripped I can't tell which one, if any, has the missing items).
We are all using Ubuntu. No problems building the image or just the E2 binary.
We are all using Ubuntu. No problems building the image or just the E2 binary.How do you just build the enigma2 binary (building the image isn't an issue).
In the image build set-up none of the sources and object files is left around.
Anyway - I've decided that, since I have a plan for the findFrame() code anyway I can flash back to 3.2-037 to test it (I have a saved image of that and of my current 4.003). Then I can set about building automake, make, and gcc5.3 for the OpenVix set-up itself (where I can install all of the dev libraries as-built), and not have to rely on a Debian mips set-up.
How do you just build the enigma2 binary (building the image isn't an issue).Mostly I just rebuild the image. Only takes about 5 minutes. And then I can just pull the update.
To just build enigma2, first time round you need to build the image. After that you can just build the module. In the example below the locations are according to my setup, and just for reference so you can find the folders:
enigma2 git location = /home/username/3.4/builds/developer/vusolo4k/tmp/work/vusolo4k-oe-linux-gnueabi/enigma2/enigma2-5.2+gitAUTOINC+f3fe89ab92-r0/git
enigma2 binary location = /home/username/3.4/builds/developer/vusolo4k/tmp/work/vusolo4k-oe-linux-gnueabi/enigma2/enigma2-5.2+gitAUTOINC+f3fe89ab92-r0/package/usr/bin/enigma2
cd /home/username/3.4/builds/openvix/developer/vusolo4k
MACHINE=vusolo4k
MACHINEBUILD=vusolo4k
. env.source
bitbake -f -c clean enigma2
bitbake -f -c unpack enigma2
(transfer modified files to "enigma2 git location")
bitbake -c package enigma2
(retrieve enigma2 binary from "enigma2 binary location")...
Mostly I just rebuild the image. Only takes about 5 minutes. And then I can just pull the update.
To just build enigma2, first time round you need to build the image. After that you can just build the module. In the example below the locations are according to my setup, and just for reference so you can find the folders:
enigma2 git location = /home/username/3.4/builds/developer/vusolo4k/tmp/work/vusolo4k-oe-linux-gnueabi/enigma2/enigma2-5.2+gitAUTOINC+f3fe89ab92-r0/git
enigma2 binary location = /home/username/3.4/builds/developer/vusolo4k/tmp/work/vusolo4k-oe-linux-gnueabi/enigma2/enigma2-5.2+gitAUTOINC+f3fe89ab92-r0/package/usr/bin/enigma2
cd /home/username/3.4/builds/openvix/developer/vusolo4k
MACHINE=vusolo4k
MACHINEBUILD=vusolo4k
. env.source
bitbake -f -c clean enigma2
bitbake -f -c unpack enigma2
(transfer modified files to "enigma2 git location")
bitbake -c package enigma2
(retrieve enigma2 binary from "enigma2 binary location")...
Many thanks never gone into bitbake before ... decided it was a step too far.... but this is very helpful:)
Mostly I just rebuild the image. Only takes about 5 minutes. And then I can just pull the update.To me that's not a development environment. A dev end is somewhere that I can play around editing the sources and check that they compile (e.g. I haven't missed out including a now-needed header file). I can test the resulting changes. Only then would I add the changes to any CMS.
After that you can just build the module.Thanks for the procedure. That looks scriptable for any module (expose, compile, cleanup) so I'll give it a go.
Thanks for the procedure. That looks scriptable for any module (expose, compile, cleanup) so I'll give it a go.Hmmm...it still parses all of the recipes before actually doing anything "real".
And, for me, it then fails with "Illegal instruction" when running aclocal (from autoreconf). Which is odd, as all I'm doing is re-running these commands on the (unchanged) full 4.003 build which I have already run and that completed OK.
Hi guys I see you guys trying hard to solve this , but I don't understand any of the tech talk :(
Just a quick questions . If a solution is found for this will it be implemented on a future update ?
Regards
Sent from my TIMEBOMB!!!
Hmmm...it still parses all of the recipes before actually doing anything "real".
And, for me, it then fails with "Illegal instruction" when running aclocal (from autoreconf). Which is odd, as all I'm doing is re-running these commands on the (unchanged) full 4.003 build which I have already run and that completed OK.It seems that I have to run it on the same system I did the original build on (I have the OpenVix build on an external SSD). Odd, given that my laptop and desktop are running the same OS.
bitbake -c package enigma2
bitbake -c compile enigma2 is simpler once you get here. Still does the Recipe checking first, though.
Well - the first pass at my "go to the I-frame in the previous or next GOP" seems to work OK on mpeg2 streams.
A test on an H.264 one was not quite so good. OK on 2x, 4x, 8x, 32x and 64x, but ended up in a little loop at 16x. It didn't hang, though, and you could get out of this by changing the speed to something else. Odd, but basically promising.
In the process I noticed that if you try to FF a downloaded movie file (it was a *.avi one) it does nothing (it has no *.ts.sc file), but the overlaid InfoBar still reports 2x, 4x, etc, speeds.
And you can't FF a radio recording....
It seems that I have to run it on the same system I did the original build on (I have the OpenVix build on an external SSD). Odd, given that my laptop and desktop are running the same OS.Looks like the build has been optimized for the later processors I have in my laptop. I suspect that doing the initial full build on the desktop system might work - or find some way to disable processor-specific optimizations in the build. Being able to use either system would be useful.
Which I'll start by writing a findFrame() which goes to the I-frame in the previous or next GOP, return a valid frame-move count and let the caller decide what to do. The present code isn't guaranteed to get out the the current GOP.OK. I've finally managed to get that coded. I've also had to change findNextPicture() (which calls findFrame()) to ensure that it always moves even if findFrame() sends it further than it wants on its first call. The effect (on my box) of not doing this is bizarre - you start a fast rewind (which is done in software) and all goes well until, at some point, the rewind becomes a hardware fast-forward without you touching anything.
The resulting findNextPicture() code is simpler, while that of findFrame() is slightly more complicated, but easier to see what it is doing (but that might also be because I've added comments).
It seems to behave itself now.
I'll post the code in a few days (off to a football match later today...) once I've tidied it up.
OK. I've finally managed to get that coded. I've also had to change findNextPicture() (which calls findFrame()) to ensure that it always moves even if findFrame() sends it further than it wants on its first call.One effect of this is that even if something happens which makes the FF/FR "loop" then the box will no longer lock-up, as it would actually flip-flop between two locations and will release the lock around the getNextPicture() call (which was the cause of the hang) as that routine is now guaranteed to return.
(But I don't think it will loop any more anyway...)
To just build enigma2, first time round you need to build the image. After that you can just build the module. I've just hit a BIG problem with this.
Someone has updated enigma2 on GIT today.
So when I run:
bitbake -f -c compile enigma2the latest enigma2 gets downloaded and built. So it appears that I can't have a constant development set-up - it is at the whim of any git changes (which isn't of much use to me)?
Someone has updated enigma2 on GIT today.
Screens/AutoDiseqc.py updated to change Astra 2 frequencies? Couldn't that be part of a separate configuration package, so that any update just changes that?
Rob van der Does
12-04-16, 05:21
E2 gets updated all the time. If that doesn't suite you, you could make your own fork (@ github or elsewhere) and only update that when you want to.
Screens/AutoDiseqc.py updated to change Astra 2 frequencies? Couldn't that be part of a separate configuration package, so that any update just changes that?That commit went to the master branch by accident. Normally the master branch only gets written to on a bump or merge.
Like Rob says, make a fork (or clone) and uses that build from. That way you are 100% in control of when it is updated.
But anyway why is the DiSEqC commit a problem? It is not a file you are working on so wouldn't cause any conflict.
That commit went to the master branch by accident.That's OK then.
But anyway why is the DiSEqC commit a problem? It is not a file you are working on so wouldn't cause any conflict.No, it doesn't. But I had to work through a diff of the complete old and new git repository (including all of the build logs....) to figure out what had actually changed.
Anyway - it's now all done....and works.
Final(?) patches
Here are the patches which fix the problem 47776. Although written for 4.003, nothing here has changed for 4.1.001, and I've already built and tested these there.
The patches are to dvb.cpp, pvrparse.cpp and tstools.cpp (all in lib/dvb of enigma2). However, since the tstools.cpp patch is a re-write of two functions (findFrame() and findNextPicture()) I've also included the full code of those separately.
I'll add separate posts to describe each patch.
At the end of all this I did some timings of running through H.264 and MPEG (H.262) in both directions.
On my MB Twin the hardware FF (2x, 4x, 8x) is actually about 1.5x, 2.5x and 5x.
Everything else (16x, 32x, 64x, 128x and all backwards ones) is actually about twice what it says it is. This isn't anything (much) to do with the changes I have made - the original code also ran at similar speeds (except when it hung).
dvb.cpp patch details.
This is something I came across when trying to figure out what some of the "standard" information in the debug logs meant, and where it came from. The code contains this:
m_skipmode_m = bitrate / 8 / 90000 * m_cue->m_skipmode_ratio / 8;and while there is a nearby comment saying, "i agree that this might look a bit like black magic." I don't think this is what it meant.
The problem is that all of the quantities on the R/h side are integers, so the calculation is done using integer arithmetic. Since the * and / operators have equal precedence it will be done left-to-right. By the time the /90000 is done the intermediate result is a small integer (it was 5 in the recording I was testing with and could easily be lower). I don't think this integer truncation is intended.
Replacing this with:
m_skipmode_m = (bitrate / 8) * (m_skipmode_frames / 8);resolves this issue (although where the second 8 comes from is a bit of a mystery). It also avoids doing the same division (m_cue->m_skipmode_ratio / 90000) twice, although it's not obvious in the original code that this was being done - it looks more like a multiplication there, but it's not.
So nothing to do with the hang, but it's always a good idea to fix bugs when you come across them.
pvrparse.cpp patch details
getStructureEntryFirst() keeps a cache of data from the ts.sc file and uses a binary search to find the entry at or preceding an offset. However, the lower-range setting has an off=-by-one error, and you'll never match the first entry.
I just happened to hit this (once). It seems to be a rare occurrence.
The effect is that it returns an entry after the given offset, which confuses the rest of the code logic (and resulted in an "impossible" loop in some fixed code I was testing).
I wrote a simple test program to call the function with the ts.sc data at the point in question, and the FAIL one shows the offset going forwards.
[parent]: grep changes FAIL.list
Offset changes from 103550600 to 103550606
Offset changes from 103550605 to 103550606
Offset changes from 103550606 to 103550606
Offset changes from 103550607 to 103550606
Offset changes from 103550608 to 103550606
[parent]: grep changes OK.list
Offset changes from 103550600 to 103521283
Offset changes from 103550605 to 103521283
Offset changes from 103550606 to 103550606
Offset changes from 103550607 to 103550606
Offset changes from 103550608 to 103550606
tstools.cpp patch details
The requirement here was that the code always move in the requested direction. The original code had problem with GOPs contain only an I-frame, as for these it could end up back where it started and then just keep looping. Some calls even went in the wrong direction, as there was a bug in the is_mpeg2 section as it forgot to call getStructureEntryFirst() to prime the cache point for its getStructureEntryNext() calls.
By ensuring that findFrame() always moves to the next I-frame in required direction, findNextPicture() can be guaranteed to return. If it has gone too far then that just means it will be asked to skip less next time.
It should now always continue in the right direction, but if some unforeseen circumstance could still prevent this then at least the code will no longer hang as the lock around the getNextPicture() call is now always being released (so you could get out of a loop by changing the FF/FR speed).
abu baniaz
13-04-16, 01:45
@Birdman, Can you upload all the affected files please?
Many thanks
checked there but did not find them
http://birdman.dynalias.org/OpenVix/
@Birdman, Can you upload all the affected files please?The zip file was attached to #116, but I've added those, and the full files and the descriptions (as html) to my patches site now.
Hi Birdman,
Are we ok to commit the 3 CPP files from here:
http://birdman.dynalias.org/OpenVix/patches/FF+FR-FINAL-code/
Sorry to but in guys , but will this be intruded on a future update ?
Sent from my TIMEBOMB!!!
Hi Birdman,
Are we ok to commit the 3 CPP files from here:
http://birdman.dynalias.org/OpenVix/patches/FF+FR-FINAL-code/Yes. I'm happy with them, and the tests I've done with them.
Sorry to but in guys , but will this be intruded on a future update ?Assuming you meant "included" that was what the question was about - whether they should be moved into the standard OpenVix sources.
Assuming you meant "included" that was what the question was about - whether they should be moved into the standard OpenVix sources.
Yes sorry included ... Apple predict txt at its best lol
Yes. I'm happy with them, and the tests I've done with them.Sorry to be a pain... but... those files aren't in sync with the versions currently on the git. Can you merge your changes into the current files please.
Sorry to be a pain... but... those files aren't in sync with the versions currently on the git. Can you merge your changes into the current files please.Done. Looks like dvb.cpp changed at some point on the way to 002.
The patches were still OK though (as they usually are...hence their use).
The patches were still OK though (as they usually are...hence their use).Thanks. I don't have any software to merge them automatically here... Windows... :D
https://github.com/OpenViX/enigma2/commit/e3f0c6dd85c3ef2c4532f827206358dc636ccb61
Thanks. I don't have any software to merge them automatically here... Windows... :DAn OpenVix box is a Linux box....:)
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.