• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

[webif] Version 1.0.10 Released

af123

af123

Administrator
Staff member
1.0.10 (03/03/2014)

  • Update to Jim 0.75;
  • Option to select audio extraction format;
  • Standard single-channel EPG was not always properly selected;
  • Fix for schedule backup page;
  • Fix for sort-by-date in mobile interface;
  • Fix for display of current automatic processing logging level on settings screen;
  • Add button to jump to current time in single channel EPG;
  • Strip redundant .00 in file size displays;
  • Fix series detection when scheduling (bug introduced in 1.0.9);
  • Replace switch with case in code (switch has been removed from Jim 0.75); add simple alias to cover common cases remaining in plugins.
 
Thanks af123. I think there still may be an issue with file size reporting though. Below is an example from the diagnostics page for rsvsync.log. Note that it claims to be 31 bytes, but is obviously larger than that.

Code: 
>>> Contents of /var/log/rsvsync.log 31 bytes
Opening /var/lib/humaxtv/rsvp.db
Attaching /var/lib/humaxtv/rsv.db
Retrieving pending records.
Attaching /var/lib/humaxtv/channel.db
Restoring any favourites.
Ignoring: no such table: fav (no such table: fav)
Attaching /var/lib/humaxtv/reorder.db
Reordering channels.
Processing 105 -> 7
Processing 106 -> 9

I also have an unencrypt.log that displays as just 'bytes' with absolutely no digits whatsoever before it, despite the file containing data.
 
rpb424 said:
I think there still may be an issue with file size reporting though. Below is an example from the diagnostics page for rsvsync.log. Note that it claims to be 31 bytes, but is obviously larger than that.
Click to expand...
Yep - 310 bytes I'd guess. Thanks, fixed.
 
Hello af123, good to now have the MP3 option in. I did a test on a past recording of Book of the Week, R4, 15 minute programme and checked the bit rate for the MP3 file that the option generates, 128 kbps. Being a bit of an audiophile I can tell the difference between 192 and 128 in MP2 and MP3. The input was 192 in MP2, so there is a level of compression going on above the input.

I suspect that you didn't decide to to make it 128 bit, but the utility that you called defaulted to this. Can I suggest that the audio quality of the programme is maintained as far as possible at the original bit rate, that way in the digitisation to MP3 we know that nothing is lost as far as possible. I know we are talking about the MP2 digital output being resampled before any one plunges in.

You could have another user selectable option 128 bit MP3 or 192 bit MP3 under the setup "Audio extraction type" keeping all parties happy as to what level of sample rate they would like in their MP3 output. That would make me happy. I know the performance time may get worse. Why the original is so fast is that it isn't doing any transcoding just junking I believe the transport layer.
 
My understanding is that there isn't a 'Keep the audio bit rate the same ' parameter for ffmpeg as there is for video (-sameq), so I think you would have to perform an ffmpeg -i input.ts to determine the original bit rate and then insert this read data into the ffmpeg conversion command. Although I'm not sure what you get if you omit the -ab parameter completely
 
Not sure when this crept in (last week or so) but the "DLNA server name" override setting seems to be having no effect.
I've re saved the change and rebooted but to no effect.
It's happened on both of my boxes.
They are on 1.03.12/2.22 plus 1.0.10-1 webif.
 
Ezra Pound said:
My understanding is that there isn't a 'Keep the audio bit rate the same ' parameter for ffmpeg as there is for video (-sameq), so I think you would have to perform an ffmpeg -i input.ts to determine the original bit rate and then insert this read data into the ffmpeg conversion command. Although I'm not sure what you get if you omit the -ab parameter completely
Click to expand...
You get 128. I think he original is actually 256.
 
Keep audio bit rate would be good, but I believe without researching it that Freeview radio is 196 and TV audio is the same. I don't think it goes higher than 196 (this is where get iplayer comes in since you get access to the high bit rates of R3 - the "HD sound"). I can see for iPod users with portable systems in theirs ears they would be happy with 128. For home systems then it should be 196 else you will hear the difference. In car, Black Holes situation I expect 128 is good enough unless you are stationary.

The bigger number the better as far as I'm concerned but it does have a cost on processing speed which is why I though you might want to make it user selectable so the choice is down to them.
 
Ah well, never mind I'm sure I can live without renaming servers.
Perhaps it will correct itself at some point.
 
Can you tell me where to find the humaxtv.log.It isn't listed on the diagnostics screen.

Is it worth removing and reinstalling the package.
 
Try running the debugtv diagnostic, this will create the humaxtv.log after rebooting your box.
 
I have just rebooted with debug tv.
Here is part of the humaxtv.log which seems to identify the problem. So something is failing:

Waiting for humaxtv to start...
Waiting for humaxtv to start...
/var/lib/humaxtv/mod/bootstrap.d/setdlnaname: Warning: no match found against known processes for 234.
/var/lib/humaxtv/mod/bootstrap.d/setdlnaname: changedlnasn returned error code -1 for process 234 (234).
[RR] Sat Jan 1 00:00:10 2000: -------------------------------------
[RR] Sat Jan 1 00:00:10 2000: Initialising v2.11
[RR] Sat Jan 1 00:00:10 2000: Got Micom TX fd = 8
[RR] Sat Jan 1 00:00:10 2000: Options 0x7
[RR] Sat Jan 1 00:00:10 2000: Timezone: GMT (0)
[RR] Sat Jan 1 00:00:10 2000: Level: ha_blue = 0x3f
[RR] Sat Jan 1 00:00:10 2000: Level: ha_rec = 0xfc
[RR] Sat Jan 1 00:00:10 2000: -------------------------------------
-------------------------------------
Initialising IR3 v1.07
IR3 debug: 0
IR3 Mode: (0x1000)
IR3 Options: 0x8
 
I can submit whole log if it helps.
Do I now need to run something to revers debugtv?

I await your advice as to what to do next.
 
Well, the DLNA server name change didn't recognise your humaxtv binary.. I'll double check that it is working on mine later before suggesting anything else to run.
 
Is this one of the things that needs updating for 1.03.12 specifically?
There are some hard coded version numbers in setdlnaname, which doesn't include 1.03.12
If so, I expect you need a memory jogger list of things to tweak every time there is a new CF :)
 
It does need updating, but I did that, didn't I? This getting older thing isn't much fun!
I'll investigate!
 
You must log in or register to reply here.
Back
Top