webif inconsistency for "change folder"

hairy_mutley

hairy_mutley

Active Member
There appears to be an inconsistency between rs and webif in the handling of change folder.
Once a scheduled recording (not series) is in the active list (i.e. not queued) the rs is able to "change folder", but on the webif the option is greyed.

As a second point, why is the change folder option not available on the queued list, only becoming available once it is in the active list?
 
Last edited:
A non-series recording cannot be recorded to a folder, regardless of what the RS appears to be able to do. That it is not greyed out is a bug in the RS.

The option to change a folder for a series recording in the pending list has been added to the WebIF. If it's not also in the RS it is because the RS development is running behind.
 
Black Hole said:
A non-series recording cannot be recorded to a folder, regardless of what the RS appears to be able to do.
Click to expand...

Cannot? or Willnot?

What if you could, perhaps using webif to alter the reservation list, make the non-series link recording 'appear' to belong to a series? e.g. sample dummy crid hummy/date/time to make it unique. The uc REc kind that appears on the rsv.dB on webif would have to be changed from O (one off recording) to 4 (series recording could specify folder) , The uc CRID type changed from 0 to 50, and webif inserts the dummy CRID.

Upside : able, using webif, to specify the folder a one off recording goes to BEFORE it is recorded. (o.k. sweeper does a good job for this AFTER it is recorded).

Downside: The one off recording appears in schedule as a 'series' (which it is not) and after recording is completed the 'series' will be placed in the schedule and clutter the schedule unless customised packages such as recomon scanned for entries with customised CRIDs to be removed from the schedule once they no longer are active.

Sweeper already does this sort of thing after the event but as webif already can change padding on the RSV.dB before the event is recorded why not customise the schedule more.
 
You may be right, but I'm not betting anything on it. If you somehow mocked up an S-CRID in the recording schedule database, would the incoming broadcast P-CRID still be recognised? If it were recognised (unaccompanied by an S-CRID), would the patched-in S-CRID still be acted on? It will be interesting to find out though.

For all but the most dedicated tinkerers, and maybe even them, my previous statement remains true.
 
Black Hole said:
If you somehow mocked up an S-CRID in the recording schedule database, would the incoming broadcast P-CRID still be recognised?
Click to expand...

Yes.

Using ftp copied RSV.dB to laptop.
I edited the setting for a once-off sheduled item. I used an editor to change one line on TBL_Reservation. I changed the value of uc CRID from O to 50. Changed the ucRecKind from O to 4 and put in a dummy szCrid.

replaced the file on the HDR *. in the secret menu I copied dB to flash, restarted the box and the reservation now had a series linked logo beside it. Webif was then able to pre-allocate it a folder.

The recording recorded fine and afterwards the schedule updated but as the series CRID was a dummy it was not acted on and now needs to be deleted.

Changing the ucCRid to 40 or 51 resulted in the schedule disappearing from the HDR after reboot.

With ucCRId at 50 I tried:
Changing the ucRecKind to 1 no series folder beside programming in schedule.
Changing ucRecKind to 2 or 3 left a green jig-saw icon beside the schedule (recording in 2 parts have this).
Changing ucRecKind to 4 spoofed a series link.
 
Border said:
The recording recorded fine and afterwards the schedule updated but as the series CRID was a dummy it was not acted on and now needs to be deleted.
Click to expand...

Do you use AR or padding? I wonder what would happen if you tried it for an event next week... the Humax periodically scans the EPG for upcoming series entries (based on the CRID) and updates the list of event IDs to look for in the now/next data. I suspect it would go dormant and drop to the bottom of the schedule.
 
I use padding. One recording was overnight but wasn't part of a series.

I will try it again and see what happens to a recording or two next 8 days.
 
af123 said:
the Humax periodically scans the EPG for upcoming series entries (based on the CRID) and updates the list of event IDs to look for in the now/next data.
Click to expand...

At first I was tried a true single non linked event.

In the past if a series CRID was changed mid series then that series schedule becomes dormant and no further updates of event IDs. If the series CRID didn't match then the schedule event shouldn't change?

At present I have a one off recording of a series next week and thanks to webif (see photo 2 ) I can allocate it to a folder.

Note the start date is 6 days ahead despite there being earlier events in that series between now and then.IMG_20150205_224905.JPG IMG_20150205_225008.JPG

I suspect after it is recorded there will be an entry with --:-- before it in the schedule I.e. like a finished series.
 
I've set up a test recording too - I use AR so it will be interesting to see what happens.
 
af123 said:
I've set up a test recording too - I use AR so it will be interesting to see what happens.
Click to expand...
Using the remote and pressing 'i' on the test recording in the schedule do the crids' on the TV screen correspond to those on the customised reservation?
 
I don't know now, but they probably did.

I scheduled a one-off of Life's Funniest Moments for 2AM today. Then modified the schedule entry by hand to change ucRecKind to 4 and szFPBRecPath to lfm. Left everything else as was, including the CRID which was type 0x31 and had a valid value.
After that tweaking, it looked like this:

Screenshot%202015-02-05%2023.45.28.png


I then rebooted five times allowing 10 minutes each time for the Humax to update the schedule (actually watched for the write events on the rsv.db to confirm that it had updated it. Point of interest, the Humax doesn't hold a lock on the rsv.db file but it does copy it into an in-memory table on startup and then periodically write it back out to disk).

After the restarts it still looked ok so I then put the box into standby and went to bed.

Redring logs shows that it woke up fine and recorded it:

Code: 
[RR] Fri Feb  6 01:59:31 2015: REC icon on.
[RR] Fri Feb  6 01:59:31 2015:  System is in standby.
[RR] Fri Feb  6 01:59:31 2015:  Changing to red.
[RR] Fri Feb  6 01:59:31 2015: Recording start 22:'/mnt/hd2/My Video/Life's Funniest Moments_20150206_0159.nts'
[RR] Fri Feb  6 01:59:31 2015:  Recording 1
[RR] Fri Feb  6 02:21:16 2015: REC icon off.
[RR] Fri Feb  6 02:21:16 2015:  System is in standby.
[RR] Fri Feb  6 02:21:16 2015:  Changing to dim blue.
[RR] Fri Feb  6 02:21:17 2015: Recording end 22.
[RR] Fri Feb  6 02:21:17 2015: Standby ring dim detected.

However, as you can see it didn't end up in the lfm folder. It has also now disappeared from my schedule.

My box took an automatic schedule backup at 01:50 when it booted to make the recording and that shows that the schedule entry looked like this at the time:

Code: 
aulEventToRecordInfo:  010001002020d454d024d454d41e0000
bRecomRsv:  0
eReady: 30
erepeat:  0
ersvtype:  3
hsvc:  65537
nduration:  1200
nsttime:  1423188000
sort:  0
szCRID: WWW.ITV.COM/24706856
szEventToRecord:  1WWW.ITV.COM/24706856|
szFPBRecPath:  lfm
szRecordedProgCrid:
szSvcName:  ITV2
szevtname:  i7Life's Funniest Moments
szsttime:  00000000000000
ucCRIDType:  49
ucInputMode:  0
ucRecKind:  4
ucVolume:  0
ulPostOffset:  0
ulPreOffset:  0
ulProgramId:  0
ulSeriesId:  0
ulslot: 19
usChNum:  0
usLastRecordedEvtId:  0
usLcn:  6
usevtid:  7892

Maybe the key is changing the ucCRIDType field along with ucRecKind. I will experiment some more.
 
Trev said:
What I can't understand why you would want to do that, other than to prove that you can.;)
Click to expand...
I'll take any opportunity to increase my understanding of the internal working.. Like you, I can't really see the point of this but different people use the box differently!
 
af123 said:
Left everything else as was, including the CRID which was type 0x31 and had a valid value.

Maybe the key is changing the ucCRIDType field along with ucRecKind. I will experiment some more.
Click to expand...

ucCRIDtype I tried was 50 and ucRecKind 4.

the szCRID above is a real one . It has to be a dummy szCRID. Also then the szCrid on the data base says one thing while using the remote and pressing 'i' on the schedule item shows the correct CRID (edit I thought that depended on a live signal but plugging out the Ariel still shows the correct crid).

It worked on a scheduled event using AR (changed single occurrence to AR using the webif).
 
Last edited:
Trev said:
What I can't understand why you would want to do that, other than to prove that you can.;)
Click to expand...
There is an advantage: I think things have been tidied up a bit now, but it has been the case that (in my case) using sweeper to relocate non-series recordings to an "unclassified" folder results in their decryption being postponed while the DLNA database catches up with the post-recording situation. If these could be recorded into the correct folder in the first place, there would be no delay.

Not that I would use it routinely, too much hassle to go around massaging the schedule for one-off recordings.
 
Border said:
It has to be a dummy szCRID.
Click to expand...
Maybe I should have rephrased that...... It could be...? Anyway

A dummy szCRID for the schedule in post 10 above meant the box did not schedule an event in the series tonight at 7.30 and the event it still for the episode now in 5 days time. Still looks like a single event being allocated to a folder (padding used not AR).
 
You must log in or register to reply here.
Back
Top