Beta [Real-time scheduling] schedule without rebooting

Status
Not open for further replies.
RSVSYNC.log

Code: 
5000    Sat Jan  1 00:00:06 2000: Final schedule entries: 48
4999    Sat Jan  1 00:00:06 2000: Slots:
4998    Sat Jan  1 00:00:06 2000: Ignoring: no such table: fav (no such table: fav)
4997    Sat Jan  1 00:00:06 2000: Restoring any favourites.
4996    Sat Jan  1 00:00:06 2000: Opening /var/lib/humaxtv/rsvp.db
4995    Sat Jan  1 00:00:06 2000: rsvsync starting, version 1.1.13.
4994    Fri Jul  3 04:46:06 2020: Loading schedule information to HumaxTV binary.
4993    Fri Jul  3 04:46:06 2020: Final schedule entries: 49
4992    Fri Jul  3 04:46:06 2020: Slots: -21
4991    Fri Jul  3 04:46:06 2020: Delete slot 21
4990    Fri Jul  3 04:46:06 2020: Found slot 21 for 7/0/1593833400/0
4989    Fri Jul  3 04:46:06 2020: Opening /var/lib/humaxtv/rsvp.db
4988    Fri Jul  3 04:46:06 2020: Schedule saved.
4987    Fri Jul  3 04:46:06 2020: Nugget is available.
4986    Fri Jul  3 04:46:06 2020: Real-time mode.
4985    Fri Jul  3 04:46:06 2020: rsvsync starting, version 1.1.13.
4984    Fri Jul  3 04:43:35 2020: Loading schedule information to HumaxTV binary.
4983    Fri Jul  3 04:43:35 2020: Final schedule entries: 50
4982    Fri Jul  3 04:43:35 2020: Slots: -52,-54
4981    Fri Jul  3 04:43:35 2020: Delete slot 54
4980    Fri Jul  3 04:43:35 2020: Found slot 54 for 3/262247/1593977400/49559
4979    Fri Jul  3 04:43:35 2020: Delete slot 52
4978    Fri Jul  3 04:43:35 2020: Found slot 52 for 3/262247/1593954000/49555
4977    Fri Jul  3 04:43:35 2020: Opening /var/lib/humaxtv/rsvp.db
4976    Fri Jul  3 04:43:35 2020: Schedule saved.
4975    Fri Jul  3 04:43:34 2020: Nugget is available.
4974    Fri Jul  3 04:43:34 2020: Real-time mode.
4973    Fri Jul  3 04:43:34 2020: rsvsync starting, version 1.1.13.
4972    Sat Jan  1 00:00:06 2000: Final schedule entries: 51
4971    Sat Jan  1 00:00:06 2000: Slots: +15,+16
4970    Sat Jan  1 00:00:06 2000: Ignoring: no such table: fav (no such table: fav)
4969    Sat Jan  1 00:00:06 2000: Restoring any favourites.
4968    Sat Jan  1 00:00:06 2000: Moving pending entry 1 to spare slot 16
4967    Sat Jan  1 00:00:06 2000: Moving pending entry 0 to spare slot 15
4966    Sat Jan  1 00:00:06 2000: Opening /var/lib/humaxtv/rsvp.db
4965    Sat Jan  1 00:00:06 2000: rsvsync starting, version 1.1.13.
4964    Fri Jul  3 00:34:50 2020: Loading schedule information to HumaxTV binary.
4963    Fri Jul  3 00:34:50 2020: Final schedule entries: 52
4962    Fri Jul  3 00:34:50 2020: Slots: -53
4961    Fri Jul  3 00:34:50 2020: Delete slot 53
4960    Fri Jul  3 00:34:50 2020: Found slot 53 for 3/262247/1593975900/49609
4959    Fri Jul  3 00:34:50 2020: Opening /var/lib/humaxtv/rsvp.db
4958    Fri Jul  3 00:34:50 2020: Schedule saved.
4957    Fri Jul  3 00:34:50 2020: Nugget is available.
4956    Fri Jul  3 00:34:50 2020: Real-time mode.
4955    Fri Jul  3 00:34:50 2020: rsvsync starting, version 1.1.13.
4954    Thu Jul  2 12:56:06 2020: Loading schedule information to HumaxTV binary.
4953    Thu Jul  2 12:56:06 2020: Final schedule entries: 55
4952    Thu Jul  2 12:56:06 2020: Slots: -15
4951    Thu Jul  2 12:56:06 2020: Delete slot 15
 
As the webif epg range was still not complete, I ran the epgrange diagnostic and found the epg went back to December, so I cleared the epg data in maintenance mode and ran fixdisk overnight.

Now the webif epg is only showing data for a couple of channels and has not loaded anything further in half an hour. Obviously this is now causing the same sync and RTS problem I had to start with.

Not sure what to try next.


Sent from my iPad using Tapatalk
 
4ndy said:
Now the webif epg is only showing data for a couple of channels and has not loaded anything further in half an hour.
Click to expand...
This sounds a bit simplistic, but have you tried changing channel (to a channel on a different mux)?
 
Black Hole said:
This sounds a bit simplistic, but have you tried changing channel (to a channel on a different mux)?
Click to expand...

Simple is often best. I hadn't thought about the data not being present in the native epg. It loaded on-screen quite quickly when I changed channels. Interestingly, there was an empty line at Ch 28 E4+1 and I found that the channel showed that nothing was tuned to that number (other boxes OK). After backing up the schedule, I did a manual retune of that mux and it was restored along with the EPG.

When I did the reboot after restoring the backup schedule, all the queued RS items went through as expected like "old school" RS on a reboot. However I have since tried to recreate this by selecting upcoming Simpson episodes in RS and rebooting, but I can't get it work when I deliberately try. I sort of encountered this yesterday, when rs.log appeared to show that it had stopped trying to schedule the queue. For whatever reason the queued items suddenly went through, along with a scheduled reboot and the items were scheduled/deleted.

The webif EPG is still not loaded.

Annotation 2020-07-04 113553.png

And rs.log is complaining about stale EPG data.

Code: 
5000    Stale EPG data, deferring schedule.
4999    *LATEST: 1593474600, TIME: 1593856500
4998    *Trying source service/event ID.
4997    *Schedule 8384/33350/1/4/Channel 4/1593856500/The Simpsons
4996    Processing command 'schedule '
4995    Stale EPG data, deferring schedule.
4994    *LATEST: 1593474600, TIME: 1593856500
4993    *Trying source service/event ID.
4992    *Schedule 8384/33350/1/4/Channel 4/1593856500/The Simpsons
4991    Processing command 'schedule '
4990    Stale EPG data, deferring schedule.
4989    *LATEST: 1593474600, TIME: 1593856500
4988    *Trying source service/event ID.
4987    *Schedule 8384/33350/1/4/Channel 4/1593856500/The Simpsons
4986    Processing command 'schedule '
4985    Stale EPG data, deferring schedule.
4984    *LATEST: 1593474600, TIME: 1593856500
4983    *Trying source service/event ID.
4982    *Schedule 8384/33350/1/4/Channel 4/1593856500/The Simpsons
4981    Processing command 'schedule '
4980    Stale EPG data, deferring schedule.
4979    *LATEST: 1593474600, TIME: 1593856500
4978    *Trying source service/event ID.
4977    *Schedule 8384/33350/1/4/Channel 4/1593856500/The Simpsons
4976    Processing command 'schedule '
 
Miraculously the webif EPG suddenly populated.

The snapshot of the RS queue I took before the EPG came back shows this:
Annotation 2020-07-04 115353.png

.. and rs.log shows this as it processed it.

Code: 
5000    _Already passed.
4999    _Found event - Football Focus
4998    *Trying source service/event ID.
4997    *Schedule 4167/13255/1/1/BBC ONE East E/1593860400/Football Focus
4996    Processing command 'schedule '
4995    _Already passed.
4994    _Found event - The Simpsons
4993    *Trying source service/event ID.
4992    *Schedule 8384/33646/1/4/Channel 4/1593859800/The Simpsons
4991    Processing command 'schedule '
4990    _Already passed.
4989    _Found event - The Simpsons
4988    *Trying source service/event ID.
4987    *Schedule 8384/33351/1/4/Channel 4/1593858300/The Simpsons
4986    Processing command 'schedule '
4985    !Error, cannot find event to schedule.
4984    *Trying event at the same time on service 8384.
4983    *Trying events at the original event time @8384
4982    *LATEST: 1594510200, TIME: 1593856500
4981    *Trying source service/event ID.
4980    *Schedule 8384/33350/1/4/Channel 4/1593856500/The Simpsons
4979    Processing command 'schedule '
4978    Stale EPG data, deferring schedule.
4977    *LATEST: 1593474600, TIME: 1593856500
4976    *Trying source service/event ID.
4975    *Schedule 8384/33350/1/4/Channel 4/1593856500/The Simpsons
4974    Processing command 'schedule '
 
4ndy said:
I hadn't thought about the data not being present in the native epg.
Click to expand...
The EPG is known to become stale unless kicked by channel changes, then it takes a while for the repopulated EPG to make it through to the CF.
 
I now know what the problem with the EPG is, though not a clue as to how or why.

My default channel on this box is Talking Pictures TV (ch 81, Com 6), (partly because I was experiencing lockups while sitting on ch 250 - not just this box). Anyway I have found that after 10-15 minutes of being on that channel the webif EPG reverts to what is shown in post #334 and RS falls over. Then after being on another channel for a while (I used BBC1), the webif EPG comes back and RS seems to function again, though in my test instance the programme is in pending - with a reboot prompt, so RTS did not work (my original issue), but that may have been due to the state of EPG at processing.

I have just confirmed this theory on two other boxes, one tuned to ch 81 and the other to ch 25 (same mux) both now have EPGs like in post #334. The EPG on the problem box has also disappeared. The native EPG on the telly just basically shows now and next apart from the channels on that mux.

I don't know why, but at least I now have a workaround. It may leave my original RTS issue unsolved for the moment, but I will keep experimenting now I can get a functioning EPG.
 
Last edited:
Sadly, there stills seems to be an issue with RS/RTS. The schedule in webif differs to the one in RS.

webif.png
Rs.png

Bean was something I scheduled via RS for test purposes.

PS the two queued items have just gone through correctly.
 
4ndy said:
My default channel on this box is Talking Pictures TV (ch 81, Com 6), (partly because I was experiencing lockups while sitting on ch 250 - not just this box). Anyway I have found that after 10-15 minutes of being on that channel the webif EPG reverts to what is shown in post #334
Click to expand...
Does this also apply to tuning to other channels on Com6?
4ndy said:
and RS falls over
Click to expand...
Please clarify, do you just mean unable to remotely schedule because of stale epg or something more dramatic.
 
4ndy said:
Sadly, there stills seems to be an issue with RS/RTS. The schedule in webif differs to the one in RS.
Click to expand...
That is common - The RS epg is taken from the first box to report after midnight and so doesn't reflect late changes. There is also a, hard to fix, bug where sometimes RS has two entries in its data base for the same time slot.
 
MymsMan said:
Does this also apply to tuning to other channels on Com6?
Click to expand...
Yes it also occurs with ch25 in a test I carried out on another box (I did say in #347, but I know I have been posting a lot)

Please clarify, do you just mean unable to remotely schedule because of stale epg or something more dramatic.
Click to expand...
Yes, rs.log reports stale EPG.


Edited to sort out quotes
 
Last edited:
MymsMan said:
That is common - The RS epg is taken from the first box to report after midnight and so doesn't reflect late changes. There is also a, hard to fix, bug where sometimes RS has two entries in its data base for the same time slot.
Click to expand...

I was referring specifically to the schedule on the "Home" page.

The thought just occurred to me that Bean - which is showing as in progress in webif, but not in RS, is the first part of a split schedule. I am not sure if I scheduled the first or second part but it may explain the anomaly.

Also if I refresh the RS page it does show momentarily. Pretty sure it is not a caching issue as the last seen time does change, get same if moving to Home from EPG.
 
Happy to report RS and RTS both now functioning as expected.

Although I have changed the default channel on that box, I record films on Talking Pictures TV quite a lot, mainly on that box.

I have already caught it on that channel twice purely because both tuners had been in use. Hopefully this is a broadcast issue and will be resolved soon. I imagine it could cause wider problems across all PVRs.

Does anyone know if it will stop AR from functioning?


Sent from my iPad using Tapatalk
 
Schedules shows AR on all reservations, though I think that refers to the type of the scheduling in CF

Looking at the start finish times for recordings on Talking Pictures TV, they all seem to show scheduled times +/- 5 seconds.

From experience the start is pretty accurate. Not bad for a channel run by a father and daughter from a shed in the garden.

My question was more about whether the AR data is part of the broken EPG data. Is, for example, the AR trigger for BBC1 carried on all muxes?

Sent from my iPad using Tapatalk
 
Last edited:
4ndy said:
Schedules shows AR on all reservations, though I think that refers to the type of the scheduling in CF
Click to expand...
It refers to the type of recording start that the Humax software utilises when padding is not being applied, and its scheduling was not set up manually.

4ndy said:
My question was more about whether the AR data is part of the broken EPG data. Is, for example, the AR trigger for BBC1 carried on all muxes?
Click to expand...
What is used as the start trigger is part of what some refer to as the now/next epg. It is carried on all muxes from the same transmitter. The internal IDs used do vary for some of the muxes between transmitters. Some recorders are better than others at coping with a mix of muxes from different transmitters - Humax is not one of the better ones.
An exception is COM7 which does carry now/next details for other transmitters.

4ndy said:
So if a box is sat on a Com 6 channel, AR may fail to track a delayed start on BBC?
Click to expand...
There will at most have an extra 8 seconds extra delay. The BBC allows for this room of error and a bit more.

What would cause issues is if you have a mix of channels from different transmitters, and the BBC channel concerned isn't BBC 1 standard definition, or you have reception issues on COM6.

4ndy said:
Probably more of an issue where box is on 24/7
Click to expand...
Yes, if the box has a mix of muxes from different transmitters, or there are reception issues on the channel you would otherwise have the box switched to when out of standby
 
Status
Not open for further replies.
Back
Top