TMSID Preservation overkill or worth exploring?

[irrelevant]

The only issue I can think of that Graham didn't address is the possibility of a clash from the opposite direction - if a new series appears that the tmsid is not known for, then a new number will be allocated, I presume sequentially. This new number needs to be checked against the new table so that it doesn't take the id of another series. This would cause problems should that one reappear too. Depending on field sizes and largest Tmsid known, this need could however be avoided simply by starting the sequential allocations higher up, rather than at 1.

[Tcm2007]

1 may be possible, but will be far from 100% accurate as it reduces everything to that text match. If the name is different in the source data, or if there two or more series of the same name (more common than you might think, esp as any past errors on Tribune's part in creating duplicate ids will be captured alongside the real ones) then it will break.

Is it better to start form scratch and have good SPs that work, or tell people that there SPs will work, but actually some of them won't?

For me it's the former.

For 2, once the TMSID is delivered in a slice you can't change it without breaking and SPs set using the original data sent. Total no-no.

[gcobb]

1 may be possible, but will be far from 100% accurate as it reduces everything to that text match. If the name is different in the source data, or if there two or more series of the same name (more common than you might think, esp as any past errors on Tribune's part in creating duplicate ids will be captured alongside the real ones) then it will break.

I agree that the TMSID assigned could well be wrong, but nothing will break in any way different from today. Tribune have made mistakes in relating names to IDs in the past and I am sure similar errors will occur again even without this change. All this does is change the ID assigned for a new series from a random number to one that maybe has some meaning for the user. I currently have over 16K ids collected and about 4% have more than one ID corresponding to a particular name. I hope to do some manual cleaning of the data for the ids which occur in the largest number of submitted SP backups and assign preferences to the mappings.

The biggest problem is not bad historical data but just that Tribune and the source for the new data will use different conventions for choosing names (with or without "The", for example). Does anyone have an example of a week of the new data feed which I can use to run some tests on (see how many exactly match Tribune names, how many are close, how many are missing altogether, etc.)? With some sample data I might be able to create a better matching algorithm -- if nothing else I can at least make sure that all current series are matched correctly.

Is it better to start form scratch and have good SPs that work, or tell people that there SPs will work, but actually some of them won't?

My guess is that about as many "won't work" as happens today when a series is restarted. Mostly Tribune get the correct info but sometimes they don't and either the SP records something it shouldn't or it misses something it should. It happens today and we live with it. With this feature, it will happen sometimes the first time a series appears after the changeover (once the series has been seen for the first time after the changeover, this logic is never invoked again for that series).

For me it's the former.

Then delete your SPs and you will never be impacted by this change, at all. For me, and for many others, it is the latter. This feature just gives people choice, without degrading the data in any way. We might even want to recommend that people delete all their SPs unless they are absolutely sure they want to make use of the "guesses" the system makes in trying to match to existing SPs.

For 2, once the TMSID is delivered in a slice you can't change it without breaking and SPs set using the original data sent. Total no-no.

Thanks. That is useful info: I was not sure if the update mechanism could handle changing IDs. As you say, that is a good reason not to go with that option.

Graham

[gcobb]

The only issue I can think of that Graham didn't address is the possibility of a clash from the opposite direction - if a new series appears that the tmsid is not known for, then a new number will be allocated, I presume sequentially.

It turns out this isn't a problem: the OzTivo ids are completely numeric, the TMSIDs all start with two letters, so there will be no clashes.

[Tcm2007]

I won't be using the new data, so it's no skin off my nose, but it feels like you should be designing the system around the new data source, not trying to re-engineer it back to a deprecated Tribune system.

Have a look in the perl scripts, but it looks to me as though it's doing more than a text match before deciding it needs to create a new TMSID; if that's right (and my perl is virtually non existent so I could be misreading it) then by preserving the old ones you'd be degrading that functionality.

[steveroe]

Have a look in the perl scripts

Have they been uploaded on this forum somewhere?

[daveh]

I must admit that I agree with Stuart on this. Why complicate the issue and potentially introduce problems down the line when it is a relatively simple matter to rebuild your Tivo's season pass list over time just as you would have to with a new Tivo. Perhaps a poll of all potential users of the new system is in order to decide which method to adopt?

[SolidTechie]

I have to say I agree too - Starting afresh with my SP list, would be a good thing - as I have a bunch of them which are old, unused and non-working duplicates. I probably still have the ITV F1 SP - just never got around to housekeeping them.

I suppose it'a a bit like upgrading the OS on your PC, if you don't insist on backwards compatibility, your horizons are increased significantly.

FWIW.

[Pete77]

I must admit that I agree with Stuart on this. Why complicate the issue and potentially introduce problems down the line when it is a relatively simple matter to rebuild your Tivo's season pass list over time just as you would have to with a new Tivo. Perhaps a poll of all potential users of the new system is in order to decide which method to adopt?

You seem to have ignored that the prime purpose of the AltEPG is to keep the service working as is without people having to start again from the ground up as though they had bought a new PVR. Many Tivos were installed by sons in the homes of parents who were non technically minded and so on.

It is unfortunate TCM2007 has managed to have so much influence on this decision when as someone who gave up using his Tivo his priorities were bound to be completely different.

[healeydave]

It's not so much Stuarts influence, Graham has plenty of experience now looking at the logistics of this and given the time constraints, I believe its more important people have an alternative source of guide data come June because after-all, Season Passes can be re-created with data available, they're pretty useless without any data to work off!

[Pete77]

It's not so much Stuarts influence, Graham has plenty of experience now looking at the logistics of this and given the time constraints, I believe its more important people have an alternative source of guide data come June because after-all, Season Passes can be re-created with data available, they're pretty useless without any data to work off!

I suppose you may be right. However the archivist in me cannot but help feel sorrow at some of those over 10 year old Season Passes on some Tivos now having to be deleted. Ditto with some of those thumbs choices from years ago being now rendered redundant.

Suggesting that people delete everything on their machine to my mind amounts to the same kind of nonsense that happens when you return your laptop computer for service requiring some piece of broken hardware on it to be fixed. It may be easier and more reliable for them to always reformat your hard drive but it isn't for you the end user and that is the whole point.

People with enlarged hard drives in their Tivos in particular are not going to be happy at the suggestion that it is better to delete everything and start from scratch although fortunately it doesn't seem to be necessary in practice.

[davidshack]

I have to say I agree too - Starting afresh with my SP list, would be a good thing - as I have a bunch of them which are old, unused and non-working duplicates.
FWIW.

I agree - the 2 tivos used by my elderly relatives will certainly have SPs that are out of date / out of favour since I set them up.
Whilst I'm changing (eg) the dialing number it'll be no big deal reviewing/reinputting SPs. And for me, that may mean returning from Switzerland. So let's not have any son moaning about distance to travel, OK?
Ditto my own 3 TiVos.

Pete, I understand your enthusiasm, but to me "the team" seem to be doing a great job in difficult circumstances & really are against the clock. Plse don't take offence when I say most of us (those who can't actually do the coding) are not posting, just keeping quiet to let them get on with the work undistracted. Thank you.

[krayzeekev]

Suggesting that people delete everything on their machine to my mind amounts to the same kind of nonsense that happens when you return your laptop computer for service requiring some piece of broken hardware on it to be fixed. It may be easier and more reliable for them to always reformat your hard drive but it isn't for you the end user and that is the whole point.

Except there's a difference - here a group of volunteers is attempting to "fake" a backend server service to a device that wasn't necessarily made to do that. Without the original server owner's cooperation. If you had their cooperation, you may get their DB with all the ID's. And other stuff. Like a signed software update to switch servers. But you're doing it as a "hack" instead. So, if the only way to get yourself an MSF and Server DB that are in Sync that don't cause slices to start failing randomly is to start again, then that's better than not having a service at all.

Trust me, having TiVo's that just fail to load any slices at all because there's one MFS entry somewhere that has become corrupted is sometimes impossible to fix. We've had such situations here. So trying to build a server that has all its data 100% matched to thousands of devices that have built up a massive internal database based on somebody else's data (without access to that data) could be next to impossible. Or at least a huge effort that won't get you running in time.

[davidshack]

Mikerr has written a TiVoweb module which "converts Season Passes to Wish Lists".
http://www.tivocommunity.com/tivo-vb/sh ... ost8531377

It should make migration to the newepg easier for those with many SPs (and who don't want to prune/update them).


I'd like to thank him for thinking through this solution, and writing it.
A constructive response to a situation.

YY

[tivofantastic]

I note from the above tivocommunity thread that TiVo is not clever enough to consider the +0 and +1 channels when doing Season Pass conflict resolution, even though "View upcoming episodes" *does* show both channels.

I wonder:

1) Now that we have control of the server side, would it be possible to do something clever (either server side or client side) so that Season Passes did indeed consider showings on both the +0 and +1 channels when performing conflict resolution. i.e. so it would only be necessary to set a single Season Pass for both the +0 and +1 channels.

2) Better still, could a Season Pass be made entirely channel independent? i.e. Rather than the TiVo code specifically knowing that a +0 channel also had a +1, would it be possible for it to simply look across all channels.

3) Currently, if a Season Pass is set up for both the +0 and +1 channels is TiVo still clever enough not to record the same episode twice? I assume it ought to be, although I know there are certain scenarios at the moment where my TiVo does seem to record repeat showings (i.e. whether that be repeats on a +1 channel or perhaps a repeat later in the week). Usually TiVo doesn't do this, but I have a feeling it may do when multiple Season Passes are set up for the +0 and +1 channels. Perhaps recording of repeat showings is just down to guide data errors? i.e. Tribune allocate a new TMSID when they shouldn't be doing?