[webif] Version 1.0.10 Released

[Ezra Pound]

Yes, obviously, but look at it!

I think in this case a picture is worth less than a few (not a 1000 please) words

 

[Luke]

It is the same with firefox and IE. I suspect it is being triggered by the change to BST.

Each passing day the EPG single channel grid view gets one more day to display correctly.
It's now fairly obvious that the issue is being triggered by the change to BST.

 

[Black Hole]

I don't get you. I'm still seeing all 8 days split.

 

[af123]

Should be better with webif 1.0.10-4
(and it is probably related to the BST change because the logic was being confused by the day changing backwards within the same hour.... somehow!)

 

[cdmackay]

Is there any chance, please, of an option to sort programme display by recording date, as opposed to filesystem date?

I turned on auto-decrypt for a directory that was nicely shown in date order, and now the date order is awry, as the files were not decrypted in that order, and it seems that webif sorts by date using the modification time of the file.

That may well be useful for some; it would be nice to also have the option to sort by recording date, for those that wish to preserve original transmission order when applying an operation like auto-decrypt.

The alternative of using numerical prefixes, and sorting by name doesn't work well - at least with original EPG series prefixes - since the filename sort isn't numeric-aware, so e.g. groups 1, 11, 2, 22, etc. I could of course rename the files 01_, 02_, etc, but that's a bit of a pain.

thanks much indeed.

 

[TonyC]

1.0.10 (03/03/2014)
<snip>

• Option to select audio extraction format;

<snip>

Thanks very much for this new feature - have just discovered that my car MP3 player doesn't like MP2 format (even when named .mp3, of course)

 

[Black Hole]

Is there any chance, please, of an option to sort programme display by recording date, as opposed to filesystem date?

Are you sure you have the up-to-date packages? This problem was sorted out a while ago.

 

[cdmackay]

Are you sure you have the up-to-date packages? This problem was sorted out a while ago.

thanks. Yes, I have all current packages:

Web interface version: 1.0.10-4​

Custom firmware version: 2.22 (build 1905)​

Humax Version: 1.03.12​

​

but webif "sorting by date" is not sorting by recording date, it's sorting by filesystem mtime.​

​

I have a directory of a series, that was shown in transmission order (sorting by date), until I enabled auto-decrypt.​

​

The current sort order shown by webif matches an "ls -ltr", rather than the previous transmission dates (which matched the original mtime stamps, before the decryptions).​

​

Is there a setting I'm missing?​

​

thanks...​

 

[Black Hole]

Sorry, I was thinking of something else (sorting on the SUI). File creation dates are now preserved during processing so that the SUI sort order is preserved, so maybe the WebIF media browser needs to sort in the same parameter.

 

[af123]

The automatic decryption (flagging a folder for automatic decryption) should reset the date stamp (mtime) on the decrypted file to match the original one and so preserve sort order. Sounds like something didn't work properly here.

 

[cdmackay]

thanks; I'm also using auto-shrink, and auto-dedupe, on the folder in question. Perhaps the auto-shrink is not resetting the mtime?

 

[cdmackay]

another point: I had auto-dedupe enabled before most of the recordings occurred, but auto-decrypt and auto-shrink flags were set after all the recordings had complete.

 

[Black Hole]

If these recordings date from a while back, the creation time will have been corrupted already.

 

[cdmackay]

They were about 2 weeks old.

 

[cdmackay]

I have several folders with this problem: all were presented in the correct, tranmission date order, until I enabled auto-decrypt/shrink. Since the auto process did not process the files in that order, their mtimes did not remain in that order; clearly, the mtime was not reset to the original.

 

[af123]

thanks; I'm also using auto-shrink, and auto-dedupe, on the folder in question. Perhaps the auto-shrink is not resetting the mtime?

Yes, I think that's right. I'll fix it.
I could also write a diagnostic to fix the recordings you have so far if it would be useful.

 

[cdmackay]

Yes, I think that's right. I'll fix it.
I could also write a diagnostic to fix the recordings you have so far if it would be useful.

thanks very much indeed, on both counts and yes please, I would love something to fix it - I was going to wade in and do them by hand - assuming the box has "touch", but something to do it properly would be great.

thanks again, much appreciated.

 

[Ezra Pound]

There is a list of available Shell / Bash type commands including 'touch' in the Wiki HERE

 

[af123]

thanks very much indeed, on both counts and yes please, I would love something to fix it - I was going to wade in and do them by hand - assuming the box has "touch", but something to do it properly would be great.

Upgrade to webif 1.0.10-6 and then run the fixtimestamps diagnostic from the web interface diagnostics screen or from the command line. That will traverse all recordings and set the filesystem timestamps to match the time the recording finished. The new webif version should keep timestamps right from now on.

 

[cdmackay]

Upgrade to webif 1.0.10-6 and then run the fixtimestamps diagnostic from the web interface diagnostics screen or from the command line. That will traverse all recordings and set the filesystem timestamps to match the time the recording finished. The new webif version should keep timestamps right from now on.

That worked perfectly, indeed. thanks so much for this, just marvellous