Quite some time ago there was a thread about managing favourites using the CF ...
[using the Humax UI] - actually creating the favorites list so that the channels appear in the correct order can be a pain.
Would it be possible to create the favourites list "off the box" and load it onto the humax? I assume it's technically possible because a favourites list created on the box can be backed up and restored using webif.
...
and as was replied
The Favourites info. is contained in *.rbk files, e.g. :- /mod/var/backup/auto-2013-Feb-22-18:06.rbk, it is worth remembering that the *.rbk files contain not only any favourites list generated but also the recording schedule list, the favourites list is quite readable, but the recording schedule is not quite so straightforward, ...
You would have to take care not to mess up the format if you edited this file
Now with the advent of Yesterday+1 in the big smoke, my list of favourites has reached 100 items, which is a limit written into the Humax blob. However the limit only applies when adding to a favourites group and is not checked afterwards (and apparently exceeding the limit doesn't blow up the software, say by overflowing some fixed buffer). So I was looking for a work-around, ideally without going into Maintenance mode and casting SQL commands to modify the Humax databases.
Edit The check is applied even if the relevant group already has more than 100 entries.
I looked at editing a copy of the autosaved .rbk file to insert Yesterday+1 into a favourites group after Yesterday; it would be a tiresome job because each data row includes an index field that would have to be incremented for every row after the inserted one.
The code to parse this file and restore the schedule and favourites data to pending copies of the relevant database tables (to replace the actual ones at startup) is in
webif/lib/rsv.class in the
restore method of the rsv class. Rather than start from scratch, I thought it would be both reasonable and much faster to modify that code.
I decided that a row should be allowed to have index "-" to mean that the restore process must assign it an index value one greater than the previous row and then increment all subsequent index values. Favourites are apparently saved into the file in ascending index order: rsv's matching
backup method extracts favourites using a SQL
order by eFavGroup, favIdx modifier and saves them in the same order, so I relied on that.
There is a test at line 1233 where if no index value has been saved it is set to 0. This didn't help my problem and I couldn't see how it would be helpful or appropriate in general: if more than one row has index 0 the restore will fail through violating index uniqueness. No doubt there is some case where it might make sense so I left it in my modified code.
Here is a difference listing against
rsv.class from WebIf 1.4.4-1:
Diff:
--- rsv.class.org 2018-04-30 18:30:16.616194000 +0000
+++ rsv.class 2018-11-26 20:44:10.291106447 +0000
@@ -1213,6 +1213,8 @@
)}
set grp 0
+ set inc 0
+ set lastidx 1
foreach line $data {
set vals [split $line "\t"]
@@ -1230,7 +1232,13 @@
lassign $vals x group type chan idx
- if {$idx eq ""} { set idx 0 }
+ if {$idx eq ""} {
+ set idx 0
+ } elseif {$idx eq "-"} {
+ set idx $lastidx
+ incr inc
+ }
+ set lastidx $idx
if {$grp != $group} {
set grp $group
@@ -1253,7 +1261,7 @@
insert into
pending.fav(favIdx, hSvc, eFavGroup, eSvcType)
values(%s, %s, %s, %s);
- } $idx $hsvc $group $type
+ } [expr {$idx == 0 ? $idx : $idx + $inc}] $hsvc $group $type
}
system restartpending
Can something like this be included in the WebIf package?
