martxw
Active Member
Hi there...
I've been working on a plug-in on top of the WebIf that includes displaying series events, and been finding some series show only the first event. Examining the raw database view shows that there is actually data in the szEventToRecord and aulEventToRecordInfo columns.
I've debugged it, and found that the field has a sensible size immediately after querying the DB in the rsv.class list proc. But after it's been passed through "new" to create an instance, and gets read again in the rsv method aul, its length appears to be just 1 byte.
As a workaround, I've cloned the code from the rsv method aul to pre-build the aul list prior to creating the new rsv instance. The aul method then just returns this pre-built aul.
The two areas of code I changed are:
and
Obviously, I'm only leaving the binary to list conversion in twice to provide some logging to highlight the issue.
Going to the WebIf schedule now puts some messy but informative logging messages near the top of the page showing where series events would otherwise have been missing. The table beneath now shows more accurate information. For me, an example of a program that had this problem is Time Team on More 4 Tues 13:30 and onwards. I don't know what causes it - perhaps particular byte sequences??
cheers...
martxw...
I've been working on a plug-in on top of the WebIf that includes displaying series events, and been finding some series show only the first event. Examining the raw database view shows that there is actually data in the szEventToRecord and aulEventToRecordInfo columns.
I've debugged it, and found that the field has a sensible size immediately after querying the DB in the rsv.class list proc. But after it's been passed through "new" to create an instance, and gets read again in the rsv method aul, its length appears to be just 1 byte.
As a workaround, I've cloned the code from the rsv method aul to pre-build the aul list prior to creating the new rsv instance. The aul method then just returns this pre-built aul.
The two areas of code I changed are:
Code:
class rsv {
ulslot -1
ersvtype 0
hsvc 0
nsttime 0
szsttime "00000000000000"
nduration 0
erepeat 0
usevtid 0
szevtname {}
ulPreOffset 0
ulPostOffset 0
ulProgramId 0
ulSeriesId 0
ucVolume 0
ucInputMode 0
usChNum 0
ucRecKind 0
ucCRIDType 0
szCRID {}
szFPBRecPath {}
szRecordedProgCrid {}
szEventToRecord {}
aulEventToRecordInfo {}
bRecomRsv 0
usLastRecordedEvtId 0
eReady 0
szSvcName {}
usLcn 0
sort 0
action 0
#BEGIN WORKAROUND
pre_made_aul {}
#END WORKAROUND
}
rsv method aul {} {
if {![exists -proc binary]} { package require binary }
set aul {}
for {set i 0} {$i < [string length $aulEventToRecordInfo]} {incr i 16} {
binary scan [string range $aulEventToRecordInfo $i $($i + 15)] \
iiii service start end event_id
catch {lappend aul [list $service $start $end $event_id]}
}
#BEGIN WORKAROUND
if { "$aul" != "$pre_made_aul" } {
puts "WARNING: $aul != $pre_made_aul"
}
return $pre_made_aul
#END WORKAROUND
}
and
Code:
proc {rsv list} {{table tbl_reservation} {extra ""}} {
set qstring "
select $table.*,
channel.TBL_SVC.szSvcName, channel.TBL_SVC.usLcn,
case when ersvtype > 3 then 1 else 0 end as sort1,
case when nsttime + nduration < [clock seconds]
then 0 else 1 end as sort2
from $table
left join channel.TBL_SVC
on $table.hSvc = channel.TBL_SVC.hSvc
"
if {$extra ne ""} { append qstring $extra }
append qstring "
order by sort1, sort2 desc, nsttime
"
#puts "QSTRING: ($qstring)"
set res [$::rsvdb query $qstring]
set records {}
foreach rec $res {
#BEGIN WORKAROUND
if {![exists -proc binary]} { package require binary }
set aul {}
set aulEventToRecordInfo [dict get $rec aulEventToRecordInfo]
for {set i 0} {$i < [string length $aulEventToRecordInfo]} {incr i 16} {
binary scan [string range $aulEventToRecordInfo $i $($i + 15)] \
iiii service start end event_id
catch {lappend aul [list $service $start $end $event_id]}
}
dict set rec pre_made_aul $aul
#END WORKAROUND
lappend records [rsv new $rec]
}
return $records
}
Going to the WebIf schedule now puts some messy but informative logging messages near the top of the page showing where series events would otherwise have been missing. The table beneath now shows more accurate information. For me, an example of a program that had this problem is Time Team on More 4 Tues 13:30 and onwards. I don't know what causes it - perhaps particular byte sequences??
cheers...
martxw...