Entries / errors on RS home page that won't clear; queued events don't process

Wildebeest

Wildebeest

Member
My remote scheduling has taken a turn for the worse.

1. on the home page it shows, at the top, a list of failed many recordings, eg:
Code: 
The following programmes failed to record:
   /[Shares] Do not delete!/NAS03/_Archive2/F1_ Monaco GP Highlights_20160529_1745 Delete failed recording
   /[Shares] Do not delete!/NAS03/_Archive2/Canal Boat Diaries_20200419_1930 Delete failed recording
They all relate to recordings stored on a NAS drive. The Humax can see the NAS drive and play the recordings.
How can I stop these items displaying? If I hit the dustbin icon, will this remove the file itself? And there are quite a few, is there a way of removing these entries in one go rather than one-by-one?

2. Queued commands never seem to be picked up and processed, they just hang about in the queue (ie in the "queued" section of the RS home page).
How can I get these to process?

Info that may (or may not) help:
  • The humax is connected by wifi
  • I recently had to replace the dongle (as it stopped worked working) with another type, but connection to the wifi network seems fine, security is set to WPA2-PSK(AES), and the RS home page confirms that the box is "seen" regularly you'd expect.
  • wondered if there was an issue that I'd deleted or manipulated files within flatview when I shouldn't, but I think that was a red herring; I've deleted the flatview package and flatview folder in any case and it's made no difference
  • the RS log is showing errors like this:
Code: 
1810    at file "/mod/lib/jim/oo.tcl", line 87
1809    at file "/mod/lib/jim/oo.tcl", line 73
1808    in procedure 'svc get' called at file "/mod/lib/jim/oo.tcl", line 52
1807    in procedure '<reference.<svc____>.00000000000000000000>' called at file "/mod/webif/lib/findhsvc", line 14
1806    in procedure 'get_channel_attr_bylcn' called at file "/mod/sbin/rs_process", line 191
1805    /mod/lib/jim/oo.tcl:87: Error: can't read "usSvcid": no such variable
1804    *Trying source service/event ID.
1803    *Schedule 28224/23360/1/82/TalkingPictures TV/1644039600/Guernsey in the 1970s - Glimpses
1802    Processing command 'schedule '

Thanks in advance

 
Wildebeest said:
They all relate to recordings stored on a NAS drive. The Humax can see the NAS drive and play the recordings.
How can I stop these items displaying?
Click to expand...
I advise you do not have the NAS virtual-USB mounted in My Video and only access it via Media >> Storage >> USB. This will prevent it being scanned for RS, DLNA indexing, thumbnail generation, and maybe corrupting the free storage calculations.

[ModSettings]/smb/<whatever>/shareFolder=off

Wildebeest said:
Queued commands never seem to be picked up and processed, they just hang about in the queue (ie in the "queued" section of the RS home page).
How can I get these to process?
Click to expand...
We might be in the lap of the gods with that one, so far as I know nobody's heard from The Authority for months. All you can do is try the rs/push, rs/sync (etc) diagnostics and hope they help.
 
MM, yes up to date with packages,
[ Humax HDR-Fox T2 (humax) 1.03.12/3.13 ]


BH, thanks:

I checked and shareFolder is set to "off".

However I do have another [ModSettings]/smb/ subfolder, a remnant from the first time I tried to hook up the NAS, which points to a different folder on the same NAS drive. There are no files in the corresponding NAS folder, it's completely empty, but for this one the [ModSettings]/smb/ shareFolder setting is "on". I will get rid of this one, it isn't used and perhaps is causing an issue.

I have now tried rs/push and rs/sync and got the following results:
Code: 
humax# rs push
Sending TBL_RESERVATION schedule information to remote server.
Already up-to-date.
Sending pending schedule information to remote server.
Already up-to-date.
humax# /mod/sbin/rs_process now
Could not acquire lock.

The "could not acquire lock" message seemed a bit odd but I tried again after a while and this time got:
Code: 
humax# /mod/sbin/rs_process now
Processing command 'schedule '
*Schedule 28224/23360/1/82/TalkingPictures TV/1644039600/Guernsey in the 1970s - Glimpses
*Trying source service/event ID.
/mod/lib/jim/oo.tcl:87: Error: can't read "usSvcid": no such variable
in procedure 'get_channel_attr_bylcn' called at file "/mod/sbin/rs_process", line 191
in procedure '<reference.<svc____>.00000000000000000000>' called at file "/mod/webif/lib/findhsvc", line 14
in procedure 'svc get' called at file "/mod/lib/jim/oo.tcl", line 52
at file "/mod/lib/jim/oo.tcl", line 73
at file "/mod/lib/jim/oo.tcl", line 87
which reflects the log entries I found. It seems to point to this missing variable "usSvcid": no such variable in jim.

I meant to add that my Humax's HDD is slowly degrading, I keep getting messages for it. I wonder if the jim package (or others) on disk was damaged, but it seems a bit unlikely.
 
This is a well-known bug in the rs package that has never been fixed.
See here for the solution.
 
Wildebeest said:
I checked and shareFolder is set to "off".

However I do have another [ModSettings]/smb/ subfolder, a remnant from the first time I tried to hook up the NAS, which points to a different folder on the same NAS drive. There are no files in the corresponding NAS folder, it's completely empty, but for this one the [ModSettings]/smb/ shareFolder setting is "on". I will get rid of this one, it isn't used and perhaps is causing an issue.
Click to expand...
The existence of a /[Shares] Do not delete! folder in My Video is a smoking gun. Delete it (but only after you've removed the automount connected with it!).
 
BH & PRPR thank you both very much. Your help is much appreciated.

So - two separate problems.

@prpr:
This is a well-known bug in the rs package that has never been fixed.
See here for the solution.
Click to expand...

Hard to believe I (and others) hadn't had problems with this not working for all this time. I didn't go through all the code to see what it does but perhaps the bug only manifests in certain situations. Anyway, I performed the code edit as per the link - many thanks for that - and pushed all the queue through.

It seemed to stop whenever it hit a past event that was no longer in the schedules so I needed to run
Code: 
/mod/sbin/rs_process now
quite a few times to push everything few. Also there seemed to be old items on the queue that were reported during this process that did not appear on the RS home page, which seemed odd.

But eventually it got to the point where everything was processed and is all now up to date 👍 and hopefully it should now stay that way.

@BH:
The existence of a /[Shares] Do not delete! folder in My Video is a smoking gun. Delete it (but only after you've removed the automount connected with it!).
Click to expand...
The strange thing is that there are "/[Shares] Do not delete!" folders for both my folders, both the one I don't use that had shareFolder=on AND the one I do use that had shareFolder=off. The latter showed underneath it folders and files that don't fully represent the current state of that NAS. I'm speculating that at some point in the past I may have had shareFolder=on for both of them and then changed the one I use to =off.

Deleting the one I don't use shouldn't be a problem, but because of the above I'm going to exercise some caution with the active one - possibly including backing up to another NAS but that will take forever so maybe not, but I'm thinking of changing the folder name on the NAS before doing anything so that should deleting the /[Shares] folder go rogue and try to delete the folder it won't find it. A bit belt and braces as removing the automount first should be enough I guess, but still...!

I'll report back when I've done this.
 
Black Hole said:
If you turn the NAS off, the link is broken and the folder can be safely deleted.
Click to expand...
Cheers BH. I've now gone through various tests, deleted the share folders, resynced, and the spurious "failed to record" messages have now gone.
The only slightly odd thing at the moment is that it doesn't want to skip an episode of a series (which I want to skip owing to two other clashing programs I also want to record). Of itself this is not an issue, so I'll monitor and see how the RS behaves after a few boot cycles.

Edit: the skip has now gone through correctly, everything's looking good.
 
Last edited:
You must log in or register to reply here.
Back
Top