mpg conversion causing slowdown and crashes

bugrain

New Member
Recently, attempts to extract to mpg (after decrypt) of SD recordings are causing my Humax to run very slow and even crash.

All packages are up to date at the time of writing.

Not sure exactly when this started, estimate it is within the last 2-3 months.

Seems to be on longer recordings (1+ hours) as I've managed to extract shorter shows (10-20 mins).

Any advice on what investigations to try would be welcome.
 
I have two HDR-FOX-T"'s .. and am only seeing the same issue on the one with the more recent updates.

The one working fine is ....
Web interface version: 1.2.2-8
Custom firmware version: 3.03 (build 2368)
Humax Version: 1.03.12 (kernel HDR_CFW_3.03)

The one that won't run the mpeg extracts without crashing out is
Web interface version: 1.4.2-6
Custom firmware version: 3.13 (build 4028)
Humax Version: 1.03.12 (kernel HDR_CFW_3.13)

Curretly copying decrypred files from machine2 to machine1 to convert.
Am considering a downgrade on the second machine.
 
According to the webif's - the working machine has a very old ... "0.10" (which sound too low) and the failing one has "2.8-1"

update: Made the mistake of updating the first machine too ... and now have the same issue there. Problem seems to be with recent version ffmpeg .. any clues how I can find a downgrade to an earlier version of ffmpeg .. as there seems to be no way of reverting to old packages?

Just speculating .. but as it seems to get progressively slower through the file until stopping dead or crashing (both machines now) .. could it be a memory leak/usage issue that does not fit on the hummy anymore?
 
Last edited:
You can revert to an earlier version on ffmeg, however there are a few problems to overcome, previous versions are available, here are two:-

http://hummypkg.org.uk/hdrfoxt2/base/ffmpeg_0.10_mipsel.opk
http://hummypkg.org.uk/hdrfoxt2/base/ffmpeg_2.8_mipsel.opk

there was also some discussion from af123 of a 2.1.4 version although it isn't available at present, the two above are downloadable and there may be others but I don't have a list of all previous versions that were available.

Because other packages depend on certain versions of ffmpeg being present, you will get an error message if you try to delete the current version of ffmpeg, although it is possible with :-
Code:
opkg remove ffmpeg --force-depends

It should then be possible to install one of the older versions with something like :-
Code:
opkg install ffmpeg_2.8_mipsel.opk --force-depends
or to re-install the current version with :-
Code:
opkg install ffmpeg

The problem of installing say ffmpeg_0.10 is that the current Webif is expecting to see ver. 2.8 or newer
 
Last edited:
Thank you Ezra for this;
"opkg remove ffmpeg --force-depends" works OK in removing ffmpeg

Unfortunately "opkg install ffmpeg_2.8_mipsel.opk --force-depends" fails with the error
* wfopen: ffmpeg_2.8_mipsel.opk: No such file or directory.
* pkg_init_from_file: failed to extract control file from ffmpeg_2.8_mipsel.opk
and I had the same issue with opkg install ffmpeg_0.10_mipsel.opk
It seem that although the file is there on http://hummypkg.org.uk/hdrfoxt2/base/ - opkg install will not find it

I then tried downloading 2.8 directly and auto loading via the usb .. ie just copying to root drive and plugging in to let it load
From the log file created .. this appeared to install 2.8 ...
Preparing package ffmpeg_2.8_mipsel.opk
Starting installation...
Installing ffmpeg (2.8) to root...
Configuring ffmpeg.
Finished installation...
but the issue with ever slowing/crashing convert still existed.

I then tried the same with 0.10 ... but I assume that because I don't get the option of adding "--force-depends" via this method
I get a log file entry that appears to not allow the downgrade ...
Preparing package ffmpeg_0.10_mipsel.opk
Starting installation...
Not downgrading package ffmpeg on root from 2.8 to 0.10.
Finished installation...
I assume this is because (as you mention above) that Webif is expecting to see ver. 2.8 or newer

I have the issue on two machines now and .. . "bugrain" has the same issue ... am surprised other are not seeing the same issue.
I have even tried going all the way back and reinstalling the stock software and then upgrading .. .still no joy.

I love the new capabilities of the newer tools... but the basics of decrypt (still working OK) and extract to mpeg and export over samba were key.

I assume there is no way of rolling the clock back to much earlier Webif and apps?
 
I thought I'd put my insomnia to some use. The issue described appears to be caused by buffer underruns in ffmpeg. This seems to be a bug that has crept into later versions of ffmpeg. I've not yet found a solution or patch (other than downgrading) and I don't know if it is fixed in the latest version (3.3.4).
The '--force-depends' flag is only needed to remove ffmpeg. Once you have done this you can install any of the available versions though, as you have observed, if you try and update directly from hummypkg.org.uk you will get version 2.8.1. harryfax - If you had removed version 2.8 (--force-depends) first before loading version 0.10 from the USB stick it would have worked. In any case if you uninstall ffmpeg, copy the ver. 0.10 opk file to 'My Video' then run the following from the command line it will work:
Code:
opkg install /media/"My Video"/ffmpeg_0.10_mipsel.opk
You will need to turn off auto-updating of packages in Webif or it will be updated to 2.8.1 again at some point. This is not ideal as it will stop the auto-updating of all other packages too. If a permanent solution cannot be found perhaps af123 could allow the user to choose version and prevent auto-update from updating ver. 0.10, thus allowing other packages to be updated automatically?
 
An "old" version of ffmpeg could be made available as a beta package (with a higher version number) - that way the auto-updating would be effectively disabled (for that package only).
 
I assume there is no way of rolling the clock back to much earlier Webif and apps?

You could revert back to the version of Web-if that you reported was O.K. in #2, i.e. Webif 1.2.2-8, but you would have to roll back all the other packages the Webif expects to find*, 1.2.2-8 has this list of dependants :-
Code:
webif-channelicons(>=1.1.18),lighttpd(>=1.4.35-2),jim(>=0.76),jim-oo,
jim-sqlite3(>=0.76),jim-cgi(>=0.7),jim-binary(>=0.76),
service-control(>=2.1),busybox(>=1.20.2-1),lsof(>=4.87),
epg(>=1.2.0),hmt(>=2.0.3),ssmtp,anacron,trm(>=1.1),
openssl-command,nicesplice,id3v2,file,rsvsync(>=1.0.2),
webif-charts(>=1.2-1),stripts(>=1.2.5-3),smartmontools,tmenu(>=1.08),
ffmpeg,id3v2,multienv(>=1.6),tcpping(>=1.1),e2fsprogs,
wireless-tools(>=29-1),dbupdate,recmon(>=2.0.3)
As you can see it doesn't say what version of ffmpeg it requires so it would be whatever was current when webif 1.2.2-8 was released, the Webif 1.2.2-8 Bundle file would contain all of the above files, e.g. a file called :-
** webif_1.2.2-8_mipsel.opb

But I'm not sure that this would install from a USB Boot as it is a downgrade, you would need to ask af123

There is also the possibility that the current ffmpeg problem could be fixed, as I guess that af123 may not want to make an older version of ffmpeg with a higher version number available, as it's not very professional

EDIT
* Having though about it an older Webif with current (Newer) packages might be O.K., not sure

** I have just downloaded and unpacked webif_1.2.2-8_mipsel.opb thinking it was a historic Bundle, however it looks like it is generated on request, so it is actually webif_mipsel.opb and contains a set of current files including webif_1.4.2-7 and ffmpeg_2.8-1
 
Last edited:
You could revert back to the version of Web-if that you reported was O.K. in #2, i.e. Webif 1.2.2-8, but you would have to roll back all the other packages the Webif expects to find*, 1.2.2-8 has this list of dependants :-
Code:
webif-channelicons(>=1.1.18),lighttpd(>=1.4.35-2),jim(>=0.76),jim-oo,
jim-sqlite3(>=0.76),jim-cgi(>=0.7),jim-binary(>=0.76),
service-control(>=2.1),busybox(>=1.20.2-1),lsof(>=4.87),
epg(>=1.2.0),hmt(>=2.0.3),ssmtp,anacron,trm(>=1.1),
openssl-command,nicesplice,id3v2,file,rsvsync(>=1.0.2),
webif-charts(>=1.2-1),stripts(>=1.2.5-3),smartmontools,tmenu(>=1.08),
ffmpeg,id3v2,multienv(>=1.6),tcpping(>=1.1),e2fsprogs,
wireless-tools(>=29-1),dbupdate,recmon(>=2.0.3)
As you can see it doesn't say what version of ffmpeg it requires so it would be whatever was current when webif 1.2.2-8 was released, the Webif 1.2.2-8 Bundle file would contain all of the above files, e.g. a file called :-
** webif_1.2.2-8_mipsel.opb

But I'm not sure that this would install from a USB Boot as it is a downgrade, you would need to ask af123

There is also the possibility that the current ffmpeg problem could be fixed, as I guess that af123 may not want to make an older version of ffmpeg with a higher version number available, as it's not very professional

EDIT
* Having though about it an older Webif with current (Newer) packages might be O.K., not sure

** I have just downloaded and unpacked webif_1.2.2-8_mipsel.opb thinking it was a historic Bundle, however it looks like it is generated on request, so it is actually webif_mipsel.opb and contains a set of current files including webif_1.4.2-7 and ffmpeg_2.8-1
What is the point in trying to rollback Webif now? The problem is in ffmpeg. It is straightforward to remove the current version and install ffmpeg 0.10 as a temporary fix. The method is described in post #7.
I will download a standalone Windows build of ffmpeg 3.3.4 and see if the problem is still there. If it fixed there may be a case for updating the version on the HDR-FOX as long as the new version does not cause any other new problems.
 
Apologies for slow response – have been away. As “MontysEvilTwin” correctly points out, I had failed to fully follow Esra’s instruction and not correctly executed “opkg remove ffmpeg --force-depends” the second time I installed from USB .. ie v0.10 – plus the great hint of installing from “My Video” will come in handy for future.

I have now done this .. and although Webif has a dependency of >2.8 .. this seems to be solving the problem on both machines, so will disable auto-update as suggested .. and keep a copy of v0.10 tucked away in case I do it by mistake and the ffmpeg still carries the bug going forward.

Thanks all – the help is much appreciated .. I hope “bugrain” who started this thread has found your help as useful as I have.
 
Apologies too for my late response - somehow I stopped getting notifications for updates to this thread.

Anyway, I too have downgraded to ffmpeg v0.10 following Ezra's instructions and this has fixed the conversion issue.

I did have one failure but I think that can be put down to running out of disk space. Also, even though it failed to convert, it did not slow down or crash the Humax.
 
somehow I stopped getting notifications for updates to this thread.
As the small print at the bottom of the notification message says
Code:
You will not receive any further emails about this thread until you have read the new messages.
You do have to visit the thread to restart the notifications
 
Back
Top