RS - Showing failed recordings from [Dustbin]

TimK2015

TimK2015

Member
Hi Folks

I have recently started using Remote Scheduling and on one machine it keeps finding "failed recordings" that are actually in my [Dustbin] folder. This is the name of the folder where Undelete keeps deleted programme for 5 days (in my case). Can anyone shed any light on this please?

RS Glitch.jpg
 
The custom firmware generally ignores files in folders with names enclosed in brackets. The default dustbin folder is called [Deleted Items]: presumably you changed the folder name to [Dustbin] in the Undelete settings tab in Webif? It may be that the RS package is only set up to recognise the default name, or there may be a bug.
 
I have used [Dustbin] for a couple of months without any problems

Capture17-06-2016-17.19.28.jpg

I have found however that the unwatched count is shown:

Capture17-06-2016-17.21.59.jpg
I was under the impression that the system ignored any folders in square brackets but perhaps this does not apply to sub-folders.
 
It's auto-processing that ignores folders prefixed "["; it would not be appropriate for other indexing-type operations to ignore them in general (although flatview does) - and the WebIF autodecrypt doesn't either.
 
It should ignore the bin when reporting failed recordings. I'll fix that.
 
Upgrade to rs version 1.4.6 and then run the rs/diskpush diagnostic (or wait overnight). The deleted entries should no longer be shown.
 
Black Hole said:
It's auto-processing that ignores folders prefixed "["; it would not be appropriate for other indexing-type operations to ignore them in general (although flatview does) - and the WebIF autodecrypt doesn't either.
Click to expand...
Thanks for the clarification BH
 
I am on RS 1.4.6 and I am getting the problem reported in this thread. My bin has the default name, [Deleted Items].
 
Thank you af123, worked well, instant solution after upgrading to 1.4.6 and running 'rs/diskpush' As I imagine you intended, I was flagged to upgrade a few moments ago when I logged into my T2.
My only concern now is if my T2 gives up the ghost as I rely heavily on its custom firmware and the remote access package.
 
MontysEvilTwin said:
I am on RS 1.4.6 and I am getting the problem reported in this thread. My bin has the default name, [Deleted Items].
Click to expand...
As long as your box has done a disk push, RS should now know the name of your dustbin and hide the failed-to-track files in that location. Can you try the rs/diskpush diagnostic if the problem is still there? If it is, please post the ID for your box so I can have a look at it.
 
af123 said:
As long as your box has done a disk push, RS should now know the name of your dustbin and hide the failed-to-track files in that location. Can you try the rs/diskpush diagnostic if the problem is still there? If it is, please post the ID for your box so I can have a look at it.
Click to expand...
I ran the 'rs/diskpush' on the two machines with the issue yesterday. I logged back into the RS website today and one had cleared. I ran the diagnostic again and now the other one is OK too.
 
Good news, thanks. As you guessed earlier, it was originally looking for the default name. The new version sends up the dustbin name along with the other disk information.
 
While it is good to ignore the dustbin for failure messages it does hide the underlying problem of why were there orphaned .hmt files in [Dustbin]/webif_autodecrypt ?Is there a problem in auto decrypt's cleanup?
 
I think it's more to do with the Dustbin's deletion of files. Sometimes the timestamp on the .hmt is newer than the other files which means it isn't expired at the same time (at least that's how it has been in the past, not sure if that's still how it works).
 
prpr said:
I think it's more to do with the Dustbin's deletion of files. Sometimes the timestamp on the .hmt is newer than the other files which means it isn't expired at the same time (at least that's how it has been in the past, not sure if that's still how it works).
Click to expand...
Spot on. The orphaned files in the bin are pretty normal and not a problem. undelete does update file timestamps as they are moved in but I suspect auto decrypt does not.
 
prpr said:
It would make sense. I would use the .ts as the key and make the rest follow regardless. There's already Jim code for stuff like this IIRC.
Click to expand...
I have started to get orphaned hmt files consistently in the deleted/autodecrypt folder over the last two weeks or so. I appreciate it is not a problem and that they will be removed on the next run.
However has any more thought been given to prpr's suggestion ?
 
Am on "rs 1.5.0-2". On the rs.hpkg.tv site I see a green message....

The following programmes failed to record:
/Countryfile/Countryfile_20180701_173

There are no orphaned files (even if I go to the root of the disk and search from there).....

humax# cd /
humax# find . -type f -name "*20180701*"

I cannot seem to get rid of the green message.
Also ran the "rs push" command, but to no avail. Please does anyone know what else can be done?

Also recent activity reads:

05/07/2018 10:33:52Could not find file '/Countryfile/Countryfile_20180701_1730.hmt' to delete.
05/07/2018 10:33:50Processing command 'delete '
05/07/2018 10:33:25System booted (Front panel button).


Thank you in advance.
 
Last edited:
You must log in or register to reply here.
Back
Top