Remote Scheduling reporting Failed Recordings which are already deleted

#1
So, since the start of July, the Remote Scheduling Portal has been repeatedly emailing me with Failed Recording notifications which I had already resolved 3 days ago! Ok, so I can turn these off in settings - but they are sometimes useful.

Failed recordings are not unusual and I normally just delete the orphan .hmt file through the web interface. This has been entirely successful on all 3 HDR T2's for many years - until this month!

The file listing presented by the Portal seems to be out of sync with the boxes, despite correctly reporting that it has seen all 3 boxes in the last few minutes. Portal does show that the orphan files still exist, but the web interface and ftp clearly indicate that they are deleted. Forcing a sync from the command line has no effect - it reports that it's already up to date. I have tried to "delete" the files again using the Portal - in the hope that this would re-sync the file lists. Perhaps unsurprisingly, this also had no effect.

A search of the forums hasn't come up with any similar issues - maybe that's me not searching correctly - or I'm just lucky.

Finally just tried completely removing just one of the boxes from Remote Scheduling and then re-registered it. Not sure what happened, but I've now lost remote scheduling for all 3 boxes! They all show in the drop down list of devices, but with no other details and no access to settings. I didn't expect that to happen! Forcing a sync from the deleted & re-registered box reports "Already up to date" again, but has no effect on the Portal - so I'm now confused. Just hope it recovers itself because the webif for all 3 reports that rs is Active. I suppose at least if I've broken it I won't get any more emails :confused:

1530702320951.png

Think I'd better stop now before I do more damage. :whistling: Any other ideas?

Edit. Re-booting my PC restored access to Portal which now shows 2 boxes as they were, but the re-registered box has not yet uploaded any data. I guess I must be doing something wrong when I try to force the sync? I used the Webshell package command line with /mod/sbin/rs_process now and rs push - both copied from the Remote Scheduling wiki. (soz cant post link)
 
Last edited:
OP
OP
Werrington

Werrington

New Member
#3
Try running the rs/sync diagnostic from the command line with diag rs/sync
Great solution. Thank you @af123. Beautifully succinct - unlike my original rambling post :oops: Soz. I'll try and do better.

Have run that command on all 3 boxes and rs is now back in sync, at least for now. We'll see what happens overnight . . . . . . . .

Maybe this should be a new post but is there a comprehensive list of command line keywords and syntax? This has raised my interest in the box code and since I date from the early days of DOS (sadly :laugh:), I am used to handling a command line - but I need a reference to get going. Any pointers gratefully received.
Cheers
 
OP
OP
Werrington

Werrington

New Member
#6
Thx @Black Hole & @Ezra Pound. I need to make the wiki my bedtime reading, I think!

There was a new failed recording last night (Great Rail Restorations with____20180704_2000). Despite deleting the hmt file with webif and doing 2 cold reboots, Portal still stubbornly shows the orphaned file over an hour later. I could now fix that manually of course - but should I just be patient and let rs do it's thing?

The RS wiki says "the box polls the server for commands every 8-12 minutes." It would seem that doesn't include disk file sync - or it's not working on my box.

Despite being a very comprehensive manual, I can't see a specific rs wiki reference - so can some wise member please say what triggers the automatic sync of disk files to Portal?
 

af123

Administrator
Staff member
#7
Despite being a very comprehensive manual, I can't see a specific rs wiki reference - so can some wise member please say what triggers the automatic sync of disk files to Portal?
As far as I remember, it occurs once a day, at around 2am or on the first boot after that. It also occurs if you do something to the files via RS instead of the web interface on the box itself - for example clicking the dustbin icon against the failed recording that shows in RS.
 
OP
OP
Werrington

Werrington

New Member
#8
Exactly right with the timing @af123 - RS Activity log - 05/07/2018 02:03:50 Updated disk contents. (and similar historically)

To try to force a disk sync, I deleted a watched media file using RS and scheduled a reboot for good measure. The selected file was deleted on the box successfully but RS didn't do a disk sync. The deleted file remained listed on Portal. All the folders kept the 2am timestamp above and today's new recordings didn't get picked up.

I'll not do a diag rs/sync, but instead post tomorrow on whether it syncs properly overnight.
 
OP
OP
Werrington

Werrington

New Member
#9
Result! The box did a disk sync at 2 am and correctly removed the orphan hmt file from the RS listing. No idea why this repeatedly failed on all 3 boxes a few days ago.

As a final test this morning, I used RS (exclusively) to delete another reported failed recording - plus a reboot. The hmt file successfully deleted on the box, but RS did not disk sync. No doubt it will tonight though. If this is expected behaviour then all is well - otherwise I may have a bug? :alien:

Thanks for the help and interest
 
Top