[rs] Remote Scheduling v1

I just got a box that said "NaN" instead of "Refreshing page" or whatever it used to say. This occurred whilst removing an item from the Queued Commands list.
Tried it again just to be sure, and it did it again.
 
Just had a very odd EPG search result on the [rs].
I searched for "building the dream".
It returned the expected 2 more4 results at Tuesday 21:00 and Wednesday 01:15, both (S5 Ep1/9)
It returned a load of matches for Building Alaska etc (not unexpected)
It also returned a rather bizarre BBC NEWS HD Tue 19 Oct 2027 02:16 with duration (16:50:06) and synopsis for (S4 Ep6/9)
Opening the Programme Details shows no title or synopsis, start, duration and type of 0

(the [webif] returns just the 2 more4 episodes)
 
I'm getting a green box at the top of the Home page of rs.hpkg.tv page informing me "The following programmes failed to record". There are 4 in all. Actually they did record as I've watched them and subsequently deleted them.

Once a week I do some housekeeping and delete the programmes I've watched from both the "Deleted Items" folder and the "webif_autodecrypt" folder leaving both folders intact (but now empty). These actions are carried out with the normal remote control

It's a mystery why "failed to record" is being reported.

The full path shown for one of these programmes is....

/[Deleted Items]/webif_autodecrypt/Predator_20160610_2200

I have clicked on the Dustbin at the end of the filename and it was queued for action. Some time later it appeared back in the "Failed to record" green box.

Investigating the "Recent Activity" log shows
"19/06/2016 16:40:46 Could not find file '/[Deleted Items]/webif_autodecrypt/Predator_20160610_2200.hmt' to delete."

Does anyone know how to get rid of the Green box and these announcements?

Thank you.
 
Just had one of those useful RS emails:

At least one failed recording has been detected in your
media library. The following recording(s) failed:

/ [FlatView]/blah​

I wonder: would it be better if the email mentioned the true location of the file, rather than the FlatView link? i.e. should RS ignore " [FlatView]" for the purposes of this check, and then it will find the problem in the real dir?

Interestingly, I did not get a matching email for the "real" dir. Is that expected? Or does it perhaps indicate that the real recording is fine, but the FlatView links aren't all there? I will check the latter...
 
The failed recording message is triggered by an orphaned .hmt file with no associated .ts and does not necessarily indicate a failure during recording but can be caused by a number of other problems where for some reason the .hmt was not deleted when the recording was deleted.

It seems we are seeing more occurrences of this message and they may be a symptom of an underlying problem that needs to be investigated.
What is causing orphaned .hmt files in the dustbin, flatview, autodecrypt folders when it appears there was no problem with the actual recording?
 
I get them too. I think they are left over from a deletion that somehow failed to delete the associated htm.
 
MymsMan said:
It seems we are seeing more occurrences of this message and they may be a symptom of an underlying problem that needs to be investigated.
What is causing orphaned .hmt files in the dustbin, flatview, autodecrypt folders when it appears there was no problem with the actual recording?
Click to expand...

I get a number of orphaned .hmt files with autoshrink, when the Hummy develops a race condition between the autoshrink process and either dedup or the box powering down. A stray copy of the .hmt file with the 'as recorded' name is left in the original place when a complete set of files with the correct name is in the new location. Easy enough to delete the stray .hmt files.
 
Whenever I use the rs package to delete a recording, it's failing and I get the error message "!Error encountered whilst processing the unschedule command - "rsv insert" method called with no object". Any ideas what I've broken?
 
FWIW my failed recordings tend to correlate with duplicate discordant rs EPG entries, e.g. MOTD2 for T2 ID 4153331520. Can I force a website database purge when I spot such impending failures?
 
I tried to use the "skip this episode" feature for the last few days, and noticed that it is not being picked up by the Humax.

All look good on the RS site, both Visual, and Schedule. But no sign of it on the Humax.

Code: 
humax1# /mod/sbin/rs_process now
Processing command 'skip 40976.40478'
*Skip 40976/40478 - 3/106/721161/1475348400/40478/1FP.BBC.CO.UK/71O258|
*No pending event
_Clydebuilt: The Ships That Made the...
/mod/webif/lib/rsv.class:321: Error: can't read "next_hsvc": no such variable
in procedure '<reference.<rsv____>.00000000000000000002>' called at file "/mod/sbin/rs_process", line 393
in procedure 'rsv set_skip' called at file "/mod/lib/jim/oo.tcl", line 48
at file "/mod/lib/jim/oo.tcl", line 65
at file "/mod/webif/lib/rsv.class", line 321
 
The RS EPG page is somewhat bust.
All the progress bars are showing weird durations. It looks like 1 hour has been added to both the elapsed time and the remaining time.
This produces some very strange effects (can't do a screenshot at the moment).
Is this DST related I wonder?
 
I never normally use the Now/Next/Later view but looking at it now I see that CBS action have achieved the miracle of simulcasting two shows on an SD TV channel :D
I had also not realised before that Jag and Star Trek are actually music shows! :)

Fullscreen capture 05112016 105638.jpg

The program details do show different crids for the programs
Fullscreen capture 05112016 110007.jpg Fullscreen capture 05112016 105945.jpg Fullscreen capture 05112016 110042.jpg
 
Even better according to RS Ideal World is currently broadcasting 3 programs simultaneously.Fullscreen capture 06112016 150137.jpg

It appears that when there is a schedule change RS is not discarding the older program information but is keeping and showing all of the programs that have been scheduled for that slot.
The grid style only shows one program per slot but often the wrong one! :(
 
You must log in or register to reply here.
Back
Top