TV Diary - add-on web interface

Hi there...

I've uploaded a new version of TV Diary: tvdiary_0.0.2-1_mipsel.opk

* There were parts of the UI that were still making me think more than I should when using it. It seemed particularly wrong that while the last recording of the day was still proceeding the table heading said "Nothing to record". That was obviously a lie. So, it now adds up the remaining recording time (within the day) for all active recordings and adds it to the heading. It also shows the projected end time of the programme in the times column, dashed and italic to follow the future event style.
new live recording.png

* Fixed problems around the day change, including the start of day offset. This was a devil to debug, and I've had to pass the browser's time on the URL to the web server for consistency, although the reported times for recording and watching are a minute out on my machines. So at 4:00am it can take a minute or 2 to start showing activity. Goodness knows what'll happen at the GMT/BST changeover. Sky+ used to get it wrong year after year.

* Also on the day change, if you have the day start set as 04:00 and go to TV Diary at 01:00 on Tuesday it defaults to showing you Monday's TV, as you've not reached the end of the TV day yet. It's like you're in a strange TV timezone!

* Fixed the split recording events, which were caused by the video file not growing within a 3 second period. Showed up a lot recording the Lords on BBC Parliament - they don't move about enough to cause the Humax to flush its buffers. The file sizes are checked over a 10 second period.

* I found and fixed a bug that caused split playback events if a chased recording ended in the 10 second gap between checking the file lengths. (The bug, only checking the second set of data for -1, rather than both, is shared with status. But there it's less likely with a 3 second wait, and the results are less visible.)

* I also changed over to check the actual video file sizes rather than use the output from lsof. Its documentation says it should be the file size, but I'm pretty sure I don't have a file 28259039358088276 bytes long! It increments by roughly 1 per second, so it's possibly a hybrid value that includes a count of buffer flushes? Anyway, I'll stick with explicitly getting the size of the file.

* I've removed the .jim extensions from the scripts in /mod/sbin to be more Unix-like. To retain the benefit of syntax highlighting in my editor I've set up a directory of symbolic links outside the package source tree. I've got the source up on GitHub https://github.com/martxw/Humax_tvdiary.git if you're interested.

* You can no longer click on a new date when the page is busy fetching the details of another date. This bug had been self-correcting but messy looking.

* I think I've finally sorted out detecting watching live TV, by adding the assumption that if you are recording a channel, and that channel is the selected one for live viewing, and you're not watching anything else or in standby, then you must be watching that channel live as well. If you have any channel other than one that's recording selected, then it assumes the box is idle. The only two times this falls down is when you go into the TV Portal and you aren't yet watching streamed video. Or if you are watching live, but someone else is streaming a video off the Humax.

Known issues:
* Occasional database is locked errors. This can appear in the recording or watching tables, or in the tvdiary.log file. In the web you can just select the day again and it refreshes correctly. If it's in the log then the worst that can happen is that a programme start or finish is out by 1 minute.

* Live watching corner case noted above. And, if you pause for a long time, it'll think you're still watching when the next programme starts.

Hopefully this is a stable release, and I can get down to leisurely watching TV, instead of cramming in 30 hours of recording a day for testing!:)

cheers...
Martin...
 
Useful package. Thank you.

I was wondering does it pull the EPG data from /epg.shtml or cgi-bin/xepg.jim. On HDR1 when I click on the Webif EPG I get xxx.xxx.x.x/epg.shtml but on HDR2 I get xxx.xxx.x.x /cgi-bin/xepg.jim

(going slightly off topic what is the difference between epg.shtml and cgi-bin/xepg.jim ?)

Would it be possible for the TV diary database to capture the EPG database when the HDR starts up and keep it for 24 hours, or keep a database of scheduled programmes with their synopsis?

If that were possible perhaps Epgpatch could then be adapted to check for programme synopsis from the saved TV diary database in preference to trying to get the synopsis from the ‘live stream’, which doesn't always work.
 
Useful package. Thank you.

You're welcome. I've very appreciative of the work everyone's put in before me.:)

I was wondering does it pull the EPG data from /epg.shtml or cgi-bin/xepg.jim.

I go for the underlying Jim/Tcl epg.class - no screen scraping. I don't really know the lifecycle of those pages.

Would it be possible for the TV diary database to capture the EPG database when the HDR starts up and keep it for 24 hours, or keep a database of scheduled programmes with their synopsis?

No. I'm trying to do the absolute minimum, for speed, reliability and disk space, and I don't store anything at all for scheduled programmes. That would take it in a completely different direction. You could probably do something better at a lower level. I run into database locking issues, and Jim doesn't seem to allow control over sqlite locking, while C++ could. I don't know whether it'd be appropriate though

If that were possible perhaps Epgpatch could then be adapted to check for programme synopsis from the saved TV diary database in preference to trying to get the synopsis from the ‘live stream’, which doesn't always work.

You've suddenly lost me there! I hadn't noticed epgpatch or the need for it. Although I have seen the Humax choose completely the wrong name for a recording file when I paused live & then started recording way later. The programme it was named after didn't appear anywhere in the recording. Querying the tvdiary database could help to correct things in that case, although I don't know whether you would need it to do exactly the same thing twice.
 
Is it now a 'stable beta'?
I'd like to try it but been waiting for the main debugging to pass as upsetting the box would incur the wrath of swmbo. :)

Oh I don't think there's been any chance of breaking the hypocritic oath and doing harm:)
My risk analysis would be that the greatest danger would be of database locking affecting the EPG. But that's never occurred. The only time I've seen DB locking issues is when I've been making updates to my own DB. I never update the EPG; its strictly read only.
The detection of file sizes is still playing up, causing split playback events, even with a 10 second delay. I'm thinking of changing to getting the video file modification times in a single pass instead. But I'll do plenty of testing before releasing a change.
 
Would it be possible to have a summary table? Something to show how many hours of TV has been recorded/viewed for the past 30 days / since TV diary was installed. It would be useful to know if you are watching less or more TV what the trend is over time.
 
Would it be possible to have a summary table? Something to show how many hours of TV has been recorded/viewed for the past 30 days / since TV diary was installed. It would be useful to know if you are watching less or more TV what the trend is over time.

Could do - I'll add it to the issues list.

Top of the list is fixing an occasional minor bug calculating the watched time - I've collected logs but haven't had time to go through them.
I'd like it to highlight when I've got too many overlapping programmes scheduled at the same time.
It'd also be useful if it highlighted when I've got something scheduled that I've already watched. E4 are particularly complicated with several concurrent series links for The Big Bang Theory.
 
I have recently installed TV diary and like the way it displays what has been recorded and what is scheduled to be recorded.

I was wondering if it would be possible to show in the display an indication of whether a recorded program has been watched, yet to be watched, deleted from disk.

Also would it be possible to add options to Watch & Delete recorded programs and Cancel scheduled recordings i.e. a subset of the functions available on the web-if Browse / Schedule menus, alternatively a link from the Diary entry to the corresponding entry on the Browse / Schedule pages.
 
OK, if we are mentioning nice-to-have features then I find using the calendar from a tablet can be a little clumsy. So it would be nice to add some buttons for next-day, prev-day, today in a larger size for simple navigation

It has been very useful in planning my emergency disk tidying - which reminds me ...
 
I've also noticed that copying files over to my external disk and also decrypting files show up in the TVDiary as items. presumably because it shows a "playing" those items while it is streaming them.
 
I was wondering if it would be possible to show in the display an indication of whether a recorded program has been watched, yet to be watched, deleted from disk.
There's no direct relationship between the information maintained in the TV Diary database and the video files. The files can change name, location and be deleted completely independently from the TV Diary DB, and I'd have to scan through them all to compare their channel and time. I don't think this is practical without being irritatingly slow to display and interfering with the Humax's day job. Already it's noticeable slower rendering the scheduled recordings rather than historical information.
Going the other way, from an individual video file to find when it was watched, would be more practicable. That could be interesting if you kept recordings around for ages, but I don't tend to keep things that long, and I'm not really that interested in more detail than seeing the watched flag.
Also would it be possible to add options to Watch & Delete recorded programs and Cancel scheduled recordings i.e. a subset of the functions available on the web-if Browse / Schedule menus, alternatively a link from the Diary entry to the corresponding entry on the Browse / Schedule pages.
I'm trying to keep to the simple focussed app mentality, and not cram too much functionality in. The diary doesn't know what files still exist, or where they are, to be able to watch them. For that I'd prefer a richer Browse page that displayed the details in a table more like the diary does than as a directory listing. I've got a backlog of a couple of months' worth of Time Team, and would like to see the summaries at the top level as I'm sure there are duplicates. I'd prefer not to have to drill into the folders either as I don't like the big context shift. When I'm looking at the videos that are available I'm not that interested in the diary aspects (the recording date is part of the file anyway) but I would be interested in knowing that I've already watched a show with the same name and summary in the past, regardless of channel and time. In order to achieve this I don't think scanning all the files when the page is rendered would work, so I'd have to think about running something in the background to maintain a DB of the summaries of the files currently on the box. And once that's in place you could start linking that with the TV Diary. But it would be quite a big leap rather than an incremental development.

As for cancelling scheduled recordings - I find having to reboot the box for the changes to take effect a big pain. At the moment my M.O. is to use the WebIf EPG to browse and 1/4 of the time use the remote to schedule a recording, but if I'm cancelling and shuffling conflicts it's mostly the remote. I don't think I can improve upon just clicking on the Schedule toolbar icon.

I find using the calendar from a tablet can be a little clumsy. So it would be nice to add some buttons for next-day, prev-day, today in a larger size for simple navigation
I wonder which tablet you have? I keep getting help from Chrome on the Nexus 7 popping up a zoomed area if I press vaguely at several links. Anyway, I've got those three buttons under the calendars on other pages I'm working on, so can add them here.

I've also noticed that copying files over to my external disk and also decrypting files show up in the TVDiary as items. presumably because it shows a "playing" those items while it is streaming them.
That's right - it's just showing up that the humaxtv process is accessing the files. I don't think there's any more accurate detail I can get to. Looking forward to the next generation of PVRs running Android if they offer more detailed APIs.

The upshot is that saying that a recorded program HAS been watched may not be correct if it's been copied etc. It's just a hint. I suppose that telling me that I've already watched a program would also be inaccurate if I'd fallen asleep while it was playing!
 
Yes, it is an N7 so it does often do the zoom thing. Or I can zoom manually it as I have to for the main Browse operations, I just knew the next, prev, today was fairly common and probably enough for my navigation needs.
 
Re Martxw reply,
I fully agree with his philosophy keep it (relatively) simple (KISS as the acronym goes).

To add all of the extra function would seem to over complicit things.

Just my view.
Keep up the good work.
 
There's no direct relationship between the information maintained in the TV Diary database and the video files. The files can change name, location and be deleted completely independently from the TV Diary DB, and I'd have to scan through them all to compare their channel and time. I don't think this is practical without being irritatingly slow to display and interfering with the Humax's day job. Already it's noticeable slower rendering the scheduled recordings rather than historical information.

Pity, I'd hoped there might be some unique programme id that would provide a quick link but if it is not straightforward I support keeping the app simple.

Going the other way, from an individual video file to find when it was watched, would be more practicable. That could be interesting if you kept recordings around for ages, but I don't tend to keep things that long, and I'm not really that interested in more detail than seeing the watched flag.
I delete most items immediately after watching and for the few that I keep have no interest in knowing when I previously watched it.

Thanks for your comment
 
Actually. it may be possible to produce an inventory of the remaining video files as a cache, instead of having to read all of the files every time it's needed or having to monitor incremental changes to the file system. You could put the summaries into a database along with the file path. When it's needed, do a quick recursive list of the video files, and discard the summary for files that no longer exist and read in the summary for just the new files. This might make things reasonably fast. You could then annotate the TV Diary listing to show which are still available or were deleted without being watched.

I'd still be more tempted to use this information to display a richer inventory of the available video files, but wouldn't want to start out replicating all of the rich functionality of the WebIf Browse page.
It'd be useful to help choose what I want to watch, but then I'd struggle to work out which of the videos visible through the TV interface using the remote correspond to the program I want to watch. It'd be nice if you could point at a file and instruct the Humax to start playing it. This would enable controlling playback through a second screen, which is what I've usually got available: either a smaller TV near the computer screens, or a tablet with the main TV.
 
A couple of comments in this thread started me thinking in whole different direction.
It'd be useful to help choose what I want to watch, but then I'd struggle to work out which of the videos visible through the TV interface using the remote correspond to the program I want to watch. It'd be nice if you could point at a file and instruct the Humax to start playing it.
and
As for cancelling scheduled recordings - I find having to reboot the box for the changes to take effect a big pain.
We also have the ir webif remote control package to allow remote control codes to be sent to the Humax.

So it might be theoretically possible to create a package which took a Scheduled recording entry, calculated the necessary sequence of remote codes needed to find the entry and delete it without needed to reboot the box.

I would assume the major problems is knowing how responsive the Humax is and building in the right length of delays to be included in the command sequence. You might also need to make some assumptions about the state of the Humax before issuing the commands
 
Back
Top