• 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] 1.5.x

There's a logical problem with the status display where I added the (delayed) case with too little thought.

When the programme being watched is from the timeshift buffer:
  • the programme name is only correct if the delay is shorter than the length of the show so far broadcast;
  • the % value shows the wrong amount through the current programme, which may also be the wrong programme.
If the status code could know the delay value, it would be possible to correct the display so that instead of
Code:
Watching (delayed) 56: That's TV (UK) - Stonehenge: The Ultimate... (16:05 - 17:55) [87%]
it would show (eg, at 17:45 today as above with delay position at 15:29)
Code:
Watching (delayed) 56: That's TV (UK) - Russian Revolution in Col... (15:05 - 16:05) [48%]
However the "obvious" way that occurred to me,
  • get the file offset of "the" TSR read file descriptor
  • calculate the programme and position from the corresponding .nts index file
fails at the first step lsof: WARNING: can't report offset; disregarding -o. I suppose this is because the CF Linux doesn't have /proc/fdinfo (and so we can't look there either :-().

Any other ideas? At a minimum s/t like this would be less misleading:
Code:
Watching delayed from 56: That's TV (UK) - Stonehenge: The Ultimate... (16:05 - 17:55) [87%]
 
Last edited:
There doesn't seem to be a specific thread for the epg package (also, the forum doesn't support searching for TLAs).

This output was shown today in the package upgrade dialog:
Code:
>>> opkg upgrade epg
Upgrading epg on root from 1.3.0-1 to 1.3.0-3...
Downloading http://hpkg.tv/hdrfoxt2/base/epg_1.3.0-3_mipsel.opk.
sh: invalid number ' 362 2198'
sh: invalid number ' 362 2198'
Configuring epg.

Should those values have been passed through s/ // ?
 
They would appear to be PIDs from the postinst, so no.
Obviously the script is a bit cr@p, but I never fell over this in testing.
I guess you have two fastepg processes running?
Part of the nastiness is that ps outputs leading zeros on PIDs and then kill interprets them as invalid numbers.
Will fix.
 
Back
Top