• 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.

TV Diary - add-on web interface

You're faster at typing than me, that's what I was going to suggest.
I see you're at a telnet prompt, so can you try "pgrep humaxtv"? The existing status command, which is used to generate the status that pops down from the toolbar in the WebIF uses "pgrep -n humaxtv". I can't remember offhand why I removed the -n, but I think it's dow when there are multiple processes.
 
I assume "status" works. I should be essentially doing the same think:
status does:
Code: 
if {[catch {set pid [exec pgrep -n humaxtv]}]} {
        puts "Cannot find humaxtv process."
        exit
}
and I do:
Code: 
try {
  set pid [exec pgrep humaxtv]
} on error { msg } {
  puts "[clock format $current_time -format {%a %b %d %H:%M (%Z)}]: Cannot find humaxtv process."
  exit
}
I'll double check the documentation for catch & try/on error, but I can't see a problem.
 
My tcl is so rusty as to be non-existent. but I tried a modified test script to see if I could figure out any more on the error. Nothing on the command line, but the web page now says "Nothing" rather than the error.
In fact maybe it was just running it (or the real one) from the command line, as the log still seems to be getting an error.

Ah and now I see results - although I see it interprets the displayed channel as "watching" - which is never going to be accurate in our case as the box is mostly left displaying a channel until it auto-offs. I was thinking it only used the items played from the media area.

Many thanks.
 
martxw said:
I assume "status" works. I should be essentially doing the same think:
I'll double check the documentation for catch & try/on error, but I can't see a problem.
Click to expand...

Jim implements try internally as a TCL function which uses catch which is why I generally prefer to just use catch. Your code looks good though and it's working on my box so I don't understand what could be going wrong here. You could log $msg to see if it contains anything useful.

Here's try since I dug it out.

Code: 
# try/on/finally conceptually similar to Tcl 8.6
#
# Usage: try ?catchopts? script ?onclause ...? ?finallyclause?
#
# Where:
#   onclause is:       on codes {?resultvar? ?optsvar?} script
#
#   codes is: a list of return codes (ok, error, etc. or integers), or * for any#
#   finallyclause is:  finally script
#
#
# Where onclause is: on codes {?resultvar? ?optsvar?}
proc try {args} {
        set catchopts {}
        while {[string match -* [lindex $args 0]]} {
                set args [lassign $args opt]
                if {$opt eq "--"} {
                        break
                }
                lappend catchopts $opt
        }
        if {[llength $args] == 0} {
                return -code error {wrong # args: should be "try ?options? script ?argument ...?"}
        }
        set args [lassign $args script]
        set code [catch -eval {*}$catchopts [list uplevel 1 $script] msg opts]

        set handled 0

        foreach {on codes vars script} $args {
                switch -- $on \
                        on {
                                if {!$handled && ($codes eq "*" || [info returncode $code] in $codes)} {
                                        lassign $vars msgvar optsvar
                                        if {$msgvar ne ""} {
                                                upvar $msgvar hmsg
                                                set hmsg $msg
                                        }
                                        if {$optsvar ne ""} {
                                                upvar $optsvar hopts
                                                set hopts $opts
                                        }
                                        # Override any body result
                                        set code [catch [list uplevel 1 $script] msg opts]
                                        incr handled
                                }
                        } \
                        finally {
                                set finalcode [catch [list uplevel 1 $codes] finalmsg finalopts]
                                if {$finalcode} {
                                        # Override any body or handler result
                                        set code $finalcode
                                        set msg $finalmsg
                                        set opts $finalopts
                                }
                                break
                        } \
                        default {
                                return -code error "try: expected 'on' or 'finally', got '$on'"
                        }
        }

        if {$code} {
                incr opts(-level)
                return {*}$opts $msg
        }
        return $msg
}
 
Could you run "jimsh" in telnet and paste the following in at the Welcome to Jim version 0.74 prompt to see if there is a difference?
Code: 
if {[catch {set pid [exec pgrep -n humaxtv]}]} {
        puts "Cannot find humaxtv process."
        exit
}
puts $pid
The type exit and try this block:
Code: 
try {
  set pid [exec pgrep humaxtv]
} on error { msg } {
  puts "[clock format $current_time -format {%a %b %d %H:%M (%Z)}]: Cannot find humaxtv process."
  exit
}
puts $pid
and exit.
In both cases you should get 180.

I'm broadly checking the same status as is shown at the top of the WebIF except I think I'm checking for video files if a few extra places as it was listing the current TV program while you're watching YouTube or iPlayer. I think it does see programs that you're streaming rather than watching on the TV, although the time spent watching is just the download time.
The the thing that might be causing problems is that I may have made assumptions that are true for a new 1.03.06 RE box, and I'm on CF 2.19.
Could you also do a "/mod/bin/lsof -p 180" (assuming the humaxtv is still process 180 for you).
 
af123 said:
I think it should work on the HD too.
Click to expand...
I installed this afternoon and I am getting the same Error: The tvdiary.db database is missing.

tvdiary.log shows that every minute since: Cannot find humaxtv process.

Note: Firmware versions below.
 
After running for some 6 hours I started getting errors in the tvdiary.log file, not sure what changed but it happened after I finished watching a 1 hour recorded programme, the 'live' TV programme it reverted back to was LCN 1 = BBC ONE W Mid (recently changed from BBC ONE) and I was wondering if that was the problem. I have also change the Settings >> TVDiary >> Start of the TV day from 00:00 to 05:00

Code: 
>>> Contents of /mod/tmp/tvdiary.log 1023.00 bytes
Thu Nov 28 00:56 (GMT): Unable to get the EPG for the program being watched on service 4165.
Thu Nov 28 00:57 (GMT): Unable to get the EPG for the program being watched on service 4165.
Thu Nov 28 00:58 (GMT): Unable to get the EPG for the program being watched on service 4165.
Thu Nov 28 00:59 (GMT): Unable to get the EPG for the program being watched on service 4165.
Thu Nov 28 01:00 (GMT): Unable to get the EPG for the program being watched on service 4165.
Thu Nov 28 01:01 (GMT): Unable to get the EPG for the program being watched on service 4165.
Thu Nov 28 01:02 (GMT): Unable to get the EPG for the program being watched on service 4165.
Thu Nov 28 01:03 (GMT): Unable to get the EPG for the program being watched on service 4165.
Thu Nov 28 01:04 (GMT): Unable to get the EPG for the program being watched on service 4165.
Thu Nov 28 01:05 (GMT): Unable to get the EPG for the program being watched on service 4165.
Thu Nov 28 01:06 (GMT): Unable to get the EPG for the program being watched on service 4165.
EDIT
The 1 Minute errors stopped when I switched from LCN 1 to LCN 101, so it does look like TV Diary is having a problem with the new BBC ONE regional names
 
I've seen the Unable to get the EPG for the program being watched on service 4165. errors a couple of times. It's only been for a short periods , near the boundary of a program, so it's difficult to debug. I Under the same circumstances "status", I think, reports just the channel name.

Yep - just found it with Dave Ja Vu. This is an odd one because DJV always seems to close down a couple of hours earlier than Dave does. WebIf says it's watching channel 25 - Dave Ja Vu. The EPG web page shows listings for the TV programs that were on Dave an hour ago, up to the scheduled close in 2 hours from now. And the Humax on-screen info says DJV is showing Close from 05:00 to 02:00!!

I think my best bet is just to say you're watching an unidentified program on that channel.

Ah - it's just passed 02:00 and Dave Ja Vu has started transmitting again, and my code's stopped logging errors. It looks like the broadcasters mucking about!
 
I'm still very baffled at the failing to find the humaxtv pid errors. That's one of the easiest parts. Can you try the two blocks of text in #26 pasted into the Welcome to Jim version 0.74 prompt, to see if there's any difference in getting the process ID.

I've come late to the game, so have no idea how different the earlier machines/standard firmware/custom firmware are from my box. A 1.03.06 RE box, with CF 2.19.

If it is just logging constant failures, do go to the tvdiary Settings and turn monitoring off, and in Diagnostics clear the tvdiary.log file. There's no point filling the disk with worthlessness.
 
Maybe try putting the absolute path to pgrep in the code. It is possible that the path in cron for earlier firmwares is not as complete.

Logging the $msg would show if that is the case.
 
Re: #26
the first block worked
The second block I had major troubles pasting it so it accepted it. But finally I think it worked.

But from my memory/experience of cron I think af123 is probably right. Since it seems to wrok when I run the script direct from the command line, but the cron job continues to log errors I think it must be the normal cron environment issue tripping things up.
 
yep seems to be working now. No more errors and the watched time is being updated.

Code: 
try {
  set pid [exec /mod/bin/busybox/pgrep humaxtv]
} on error { msg } {
  puts "[clock format $current_time -format {%a %b %d %H:%M (%Z)}]: Cannot find  humaxtv process.\[$msg\]"
  exit
}
 
I supposed I should update. Especially since I just realised it is over 3 years old now and people have reported disk issues as they get older. One of the later versions has better/friendlier disk-fix I gather? Not sure when I will have time and a suitable slot to do a FW upgrade though.
 
cloud9 said:
One of the later versions has better/friendlier disk-fix I gather? Not sure when I will have time and a suitable slot to do a FW upgrade though.
Click to expand...

Well, fix-disk is one of the things that has generally improved with each release. Version 2.19 is recommended for anyone wanting to check/fix their disk.

CFW 2.20 is coming in the next week or two so it might be worth waiting if you're looking to upgrade.
 
Hi... I'll try again. I didn't expect hitting space to submit a post!

I've uploaded an update - tvdiary_0.0.1-3_mipsel.opk - to hopefully fix the defects reported.

1) tvdiary_status.jim failing to find the humaxtv PID under crontab.
I've put in the full path to /mod/bin/busybox/pgrep, and ensured the full path is used in all execs, and that the caught error message is logged too.
If there are still problems, I've put a couple of commented out lines at the top, to be uncommented in order to print the environment variables. I've noticed considerable differences between the environment seen by command-line and crontab, although not in the PATH on my machine. I have tried calling a script from crontab that cuts down the PATH & then calls tvdiary_status.jim, but that only managed to completely stop it running rather than reproduce the problem.

2) Programs without EPG entries logged as errors rather than added to the DB.
I've changed to record the channel name, then have "Not in EPG" as the name and "No information available" as the synopsis. This situation is most easily reproduced by watching CBBC in the middle of the night, or the adult channels in the middle of the day.

I haven't done anything about periodically purging the DB of aged data yet. But I think it would be useful to link that with pushing the recorded/watched information out to a remote hosting server. The information would then be available whether the Humax is turned on or not, and you don't have to make your Humax visible outside your firewall.

For showing more than one day's data I suggested calling the ajax sequentially to get several days data, and you could put date headers between them. A catch with this is that programs that span 2 days would appear on both days. So it'd probably need an option to say whether to include spanning programs at the beginning or end of the day, or both. While the day spanning code is being messed with, the requirement to only report whole days could also be removed. Totting up the total hours recorded or watched also needs to be considered, as that takes account of day boundaries and spanning programs.

I'd quite like to change it to return XML rather than a table, and use CSS to style it as a table. That way there's more flexibility to include the date in there as well as the time, and then decide whether to make it visible or not.

I think it also might be useful to distinguish watching recorded programs and watching live TV. I think this would help with what @cloud9 was alluding to in #24, and for me I leave the Humax on all night because it feeds to old pre-digital TV I use as an alarm clock. I'm not sure I'd immediately change the way it's displayed, but if it's rendered in XML one could use CSS to change the way it's displayed without having to change the CGI at all.
 
You must log in or register to reply here.
Back
Top