[Mut@nt HD2400] Software crash when fast forward a recording

[twol]

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

 

[birdman]

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.

 

[birdman]

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.

 

[rico_3000]

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!!!

 

[birdman]

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.

 

[birdman]

bitbake -c package enigma2

bitbake -c compile enigma2

is simpler once you get here. Still does the Recipe checking first, though.

 

[birdman]

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....

 

[birdman]

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.

 

[birdman]

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.

 

[birdman]

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...)

 

[birdman]

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 enigma2

the 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)?

 

[birdman]

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]

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.

 

[Huevos]

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.

 

[birdman]

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.

 

[birdman]

Final(?) patches

Here are the patches which fix the problem View attachment FINAL-code.zip. 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).

 

[birdman]

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.

 

[birdman]

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

 

[birdman]

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]

@Birdman, Can you upload all the affected files please?
Many thanks
checked there but did not find them

http://birdman.dynalias.org/OpenVix/