Prioritize Shows

[wally3218]

Does anyone else think it be great if we could prioritize our favourite tv shows in IceTv Interactive.
So when there's multiply favourite shows on at same time we can choose which ones we want to record
At the moment you have to change which recorded shows you want and cancel the one thats least favourite.

[grampus]

Does anyone else think it be great if we could prioritize our favourite tv shows in IceTv Interactive.
So when there's multiply favourite shows on at same time we can choose which ones we want to record
At the moment you have to change which recorded shows you want and cancel the one thats least favourite.

You mean, weight them from 1 - 100?

[wally3218]

Yes rate them from 1 to 100 that way if theres 3 shows due to be recorded at the same only the top 2 shows will be recorded.
This would be suitable for dual tuner recorders that can only record 2 shows at same time.
With the new recorders that can handle 4 shows the top 4 shows would be recorded.

[prl]

So... rate all your (prime time?) shows 1..100?

[Lisey]

Good god.  Who has the time to do that?
It easy to look at what shows are recording and remove your least favorite.

[prl]

Good god.  Who has the time to do that?
...

Exactly what I was thinking.

[_DrifteR_]

I don't think you need to rate them all from 1 to 100, my preference would be to order them, like I did on my old toppy 5k- epg tap (can't remember the TAPs name). Initially the order (or rank) is created as the timers are created. Then you move the timers up or down the list to 'rank' them as you want. From experience with the toppy, most recordings don't conflict, however when they do, you have a pre-arranged preference for your tuners.

[prl]

I don't think you need to rate them all from 1 to 100, my preference would be to order them, like I did on my old toppy 5k- epg tap (can't remember the TAPs name). Initially the order (or rank) is created as the timers are created. Then you move the timers up or down the list to 'rank' them as you want. From experience with the toppy, most recordings don't conflict, however when they do, you have a pre-arranged preference for your tuners.

I'm not sure how you display and manipulate the set of disjoint partial orderings that this implies. Clearly the TAP did something useful, but I can't work out what from the description. It will be a set of disjoint partial orderings if all you see in one conflict resolution is the set of recordings that are currently actually in conflict. It will reduce to a single strict total order if at each conflict the whole set of recordings on IceTV is listed. For me that's about 150 recordings, and I don't want to have to deal with that.

You get a partial ordering when you have not specified pair-wise preferences between all possible pairs of items. You get a strict total order when all pair-wise preference have been defined. A total order can be mapped one-to-one to a subset of the integers (that would imply that each recording has a unique preference ranking applied to it), and ordering items in a single list implies a strict total order between all of them (because each item is mapped to its position in the list).

A single preference order list may be workable for the list of manually created timers that are typically on a PVR at one time, but I don't think it's well suited to something like IceTV.

Anyway, I would only want a scheme like this to be applied after some sort of preference scheme of where the recording would be made was applied - I'd want things recorded with my DP-Lite as first preference, then as second preference on my DP-H1, and only if that failed, some sort of automated decision about not recording something. The scheme would also need to take into account whether padding in sequential recordings on the same service is better preserved by running the recordings on the same PVR (and catching the end of the first program in the second recording), or moving one of the recordings to another PVR and getting post-padding on both.

I have a feeling that it would be hard to make something automatic that I could rely on as much as sorting out these relatively infrequent conflicts manually.

[cam]

I don't think you need to rate them all from 1 to 100, my preference would be to order them, like I did on my old toppy 5k- epg tap (can't remember the TAPs name). Initially the order (or rank) is created as the timers are created. Then you move the timers up or down the list to 'rank' them as you want. From experience with the toppy, most recordings don't conflict, however when they do, you have a pre-arranged preference for your tuners.

Sounds like Jags EPG.  That's what I used to use, and I found it pretty good.

Cam

[_DrifteR_]

prl, I had to read your reply a couple times, but I think I  understand now and I agree, it would be hard to implement on IceTV where potentially multiple pvrs are linked to the same account. I hadn't thought of that as I only have one pvr.

To get something implemented that was rock solid may be difficult, but a simple list of recording in some sort of order would be good IMO (a one pvr account holder). So the logic is simply, if no.4 and no.16 clash, no.4 takes precedence. I'm not talking a total overhaul of the inner workings of ICETV, just allowing user access and editing to the order recording are sent to the pvr/s. So out of interest, how are my recordings ordered? If I was trying to record 3 things on different channels at the same time which recording would fail? Is it alphabetical, chronological (from when timers set first setup), LCN dependent or something I haven't thought of?

By the way, the tap on my Topfield 5000 was called "auto-scheduler".

[prl]

prl, I had to read your reply a couple times, but I think I  understand now and I agree, it would be hard to implement on IceTV where potentially multiple pvrs are linked to the same account. I hadn't thought of that as I only have one pvr.

To get something implemented that was rock solid may be difficult, but a simple list of recording in some sort of order would be good IMO (a one pvr account holder). So the logic is simply, if no.4 and no.16 clash, no.4 takes precedence. I'm not talking a total overhaul of the inner workings of ICETV, just allowing user access and editing to the order recording are sent to the pvr/s. So out of interest, how are my recordings ordered? If I was trying to record 3 things on different channels at the same time which recording would fail? Is it alphabetical, chronological (from when timers set first setup), LCN dependent or something I haven't thought of?

By the way, the tap on my Topfield 5000 was called "auto-scheduler".

I haven't seen the TAP mentioned in the discussion, but I have about 150 series recordings in IceTV. I'm not sure how the system would work with that sort of number of recordings to rank. I'm not even sure that such a ranking has much meaning. It would also probably need to take into account whether something is a first run - if I have two series recordings ranked 47 and 47, both set for first runs and repeats, and there's a clash between 47 and 48, but 48 is a first run, but 47 is a repeat, which should go through? These are problems even without the added complexities of multiple PVRs.

I think that prioritisation is a superficially attractive idea, but I really can't see how it should be made to work.

For managing recordings across multiple PVRs, I'd like to be able to see all my recordings for all PVRs on one Web page, rather than having to keep flipping between them when I'm trying to work around a period of heavy recording activity. I get few enough clashes that just this would do - no automation necessary.

I'd also really like it if I didn't get the hollow donut for "queued recording" or the yellow error triangle for timers that have been successfully sent to my Beyonwiz recorders. There seems absolutely no pattern to what causes that.

[grampus]

For managing recordings across multiple PVRs, I'd like to be able to see all my recordings for all PVRs on one Web page, rather than having to keep flipping between them when I'm trying to work around a period of heavy recording activity. I get few enough clashes that just this would do - no automation necessary.

Probably going over old ground here, But, I have previously requested this feature.
It currently works in that fashion on the IPAD APP.

I'd also really like it if I didn't get the hollow donut for "queued recording" or the yellow error triangle for timers that have been successfully sent to my Beyonwiz recorders. There seems absolutely no pattern to what causes that.

I haven't seen that so much anymore., after I placed a dummy device as the first one in the Website setup.  This one doesn't ever have timers set.
Expanding that, it seemed on my setup that there was an issue with the selection of the device in the BW's list, on odd occasions the second device in the list would request timers for the first one in the list.  Under these conditions with a dummy in the first position, no timers are sent if selected erroneously.  Generally it seems that probably on the next request cycle the correct ID is sent, and the new timers are sent to the correct box.
##Phew##
Hope that makes sense.

[prl]

...

I'd also really like it if I didn't get the hollow donut for "queued recording" or the yellow error triangle for timers that have been successfully sent to my Beyonwiz recorders. There seems absolutely no pattern to what causes that.

I haven't seen that so much anymore., after I placed a dummy device as the first one in the Website setup.  This one doesn't ever have timers set.
Expanding that, it seemed on my setup that there was an issue with the selection of the device in the BW's list, on odd occasions the second device in the list would request timers for the first one in the list.  Under these conditions with a dummy in the first position, no timers are sent if selected erroneously.  Generally it seems that probably on the next request cycle the correct ID is sent, and the new timers are sent to the correct box.
##Phew##
Hope that makes sense.

It makes sense, but doesn't seem all that relevant.

I've never has an issue with one of my Beyonwizes getting timers that were supposed to go to the other. In the problem I'm talking about, the timer is sent to the correct PVR, but remains flagged as not sent, or is flagged as an error.

[raymondjpg]

I've never has an issue with one of my Beyonwizes getting timers that were supposed to go to the other. In the problem I'm talking about, the timer is sent to the correct PVR, but remains flagged as not sent, or is flagged as an error.

I have an instance today of a IceTV scheduled recording which, by the looks of it, was originally registered in the BW as starting at 4.55 pm. Both the Ice Interactive web site and the most recent XML guide from Ice (as at 2.00 pm) now show start time as 4.00 pm.

Rather than modify the start time of the scheduled recording in the BW, the Ice Interactive site first had a persistent red doughnut and now has thrown a yellow triangle error. The start time of the show on the BW is still 4.55 pm.

In this particular case, F1 in China, the original Ice schedule may have had two entries - a pre-race show starting at 4.00 pm and the main race at 4.55 pm. If this was combined into one entry on the Ice server, and that one entry was not exactly as per the one scheduled in my BW as starting at 4.55 pm, maybe that would account for the triangle error.

On the other hand the second tuner in the BW is free from 3.20 pm, and one would have thought that a new timer might have been sent to the BW, giving me two scheduled entries for the China F1.

I was under the impression that the Ice servers could modify start and finish times of BW schedules in the PVR, having been advised (for example) that with the change from DST it was a mistake to delete timers on the BW before resending them from the Ice server. Maybe resending timers from the Ice server would resolve some yellow triangle issues. If that is the case, then it doesn't seem too much of a stretch for the Ice servers to automatically reconcile what is currently scheduled on the Ice site with what might be scheduled in the PVR.

[grampus]

It makes sense, but doesn't seem all that relevant.

I've never has an issue with one of my Beyonwizes getting timers that were supposed to go to the other. In the problem I'm talking about, the timer is sent to the correct PVR, but remains flagged as not sent, or is flagged as an error.

I also have seen this type of thing, but not recently.  Doesn't mean that it didn't happen after I had put the dummy in.

When the BW receives the timer, as it should,  it then has to acknowledge the fact that it got it back,  to Ice.
Now i'm assuming that there is a problem in the BW, and is caused by some erroneous logic, that makes the BW call for the wrong device,
So here's my whatif.
What if when the BW tries to respond with an acknowledgement to Ice that it has set the timer, and that ack  has the wrong device number set in it.
That may explain the red doughnut.  I.E didn't get the ack back with the right device set in the response, and it went into the big bit box in the Ice server.
As it is still a red doughnut, when the BW tries again in half an hour, then Ice tries to send the timer again, but due to the fact that the timer is already set in the BW, it then sends back an error.

Don't know enough about the protocol, and its all guess work.