WebIF "Shrink" option

I'm loving that. As soon as I've confirmed undelete is working and the general runes are good I shall unleash it on my radio library!
 
I think this may have some problems with files over 4GiB (thanks to xyz321 for letting me know). Please don't use it on any large recordings until I've had a chance to look into it.
 
I think this may have some problems with files over 4GiB (thanks to xyz321 for letting me know). Please don't use it on any large recordings until I've had a chance to look into it.
Sorry, this particular problem recording had a size of 3.8GiB. I wonder if there was a brief dropout although I can't see any evidence of it on the original recording.

For info... The problem appears as a negative number in the report. The Humax will refuse to play the shrunken file beyond a particular point in the recording and will not FF or jump into that region.

Code:
.Saved: 1124708/20018026 packets, 205.94/-430.59 MiB (5.62%)
 
I think this may have some problems with files over 4GiB (thanks to xyz321 for letting me know). Please don't use it on any large recordings until I've had a chance to look into it.
I tried a 4.8GB file today. The progress bar stopped at 41% but the file continued to grow for a further 10 minutes or more. Eventually, it stopped growing and the bar went to 100% and the process terminated. The file was only 3% smaller that the original, so I don't think I'll be using it often, but the output was usable.
 
Code:
humax# du -hs \[Deleted\ Items\]/webif_autoshrink/The\ Big\ Bang\ Theory/
57.5G    /mod/video/[Deleted Items]/webif_autoshrink/The Big Bang Theory/
 
humax# du -hs The\ Big\ Bang\ Theory
47.6G    The Big Bang Theory

ecstatic.jpg
 
Sorry, this particular problem recording had a size of 3.8GiB.
ok.. hmm... I have taken care to use 64-bit datatypes throughout but I thought I must have missed something. I've seen the negative summary though so I should be able to reproduce it.
 
The negative summary turns out to be a cosmetic thing (fixed in the version I've just uploaded). I've also pushed up a new web interface which should fix the stray icon problem.
 
This new version has reduced the number of stray icons, but I still have a couple left.
Interesting. The ones with stray icons must have no EIT packets at all in the first 15,000 packets... (so they look shrunk)
 
Interesting. The ones with stray icons must have no EIT packets at all in the first 15,000 packets... (so they look shrunk)
Is there anything that I can do to check? Both programmes are from BBC HD, one is 60 mins and the other is 10 mins.
 
If you upgrade the stripts package to 1.0.5, the you can see where the first EIT packet is from the command line:

Code:
humax# stripts -c /mnt/hd2/My\ Video/Diamond\ Jubilee/The\ Diamond\ Jubilee\ Carriage____20120605_1347 
12463
Processed in: 0.46s

Use tab a lot to automatically complete the filenames!
 
If you upgrade the stripts package to 1.0.5, the you can see where the first EIT packet is from the command line:

Code:
humax# stripts -c /mnt/hd2/My\ Video/Diamond\ Jubilee/The\ Diamond\ Jubilee\ Carriage____20120605_1347
12463
Processed in: 0.46s

Use tab a lot to automatically complete the filenames!
I tried this, but couldn't get it to work.
 
I tried this, but couldn't get it to work.

In the example above the file The Diamond Jubilee Carriage____20120605_1347 will be this in full :-
The Diamond Jubilee Carriage____20120605_1347.ts BUT you must not include the '.' or the 't' or the 's'
if you use the TAB key the file will probably end in a '.' so you have to backspace to remove it
 
Would it not make sense to allow the auto functions to work on folders and their sub-folders?
And could not the auto-dedulp move duplicates into the dustbin like the auto-shrink or are they already deleted after a certain time?
Thanks. It's really coming together.
 
I have finally worked out how to do this, so here are the results from my stray icon files.
Code:
humax1# stripts -c /mnt/hd2/My\ Video/Coast_20120605_1720
0
Processed in: 0.09s
humax1#

Code:
humax1# stripts -c /mnt/hd2/My\ Video/Coast_20120603_2100
0
Processed in: 0.09s
humax1#
 
Sorry, this particular problem recording had a size of 3.8GiB. I wonder if there was a brief dropout although I can't see any evidence of it on the original recording.

The problem seems to be with any recording over 2GiB (rather than 4GiB). Still investigating.
 
Please update your webif/stripts packages. This version fixes the problem with recordings over 2GiB.
 
If the Humax software uses a sql database to store programme info could another database be added that could hold CF information about files that have been processed, ie uncrypted and shrunk.
 
Back
Top