Vanished - ch7 - Mondays

[impact]

CONSISTENCY GUYS !!!!

I recorded Vanished last week - a new series... not sure what it would be like, but set it up for a series recording just in case I liked it... Well with the power of the PVR, I finally got around to watching it... And thats fine - so a quick check in MCE to see when its on next... and no further showings were available.

So I started to wonder what is on next Monday in its place ? Turn to the EPG and Vanished is on.... Doh? Why is it not being recorded?

Then I found it - last week the title of the show was "Vanished (US 2006)", next week the show is called "Vanished".


Seriously guys, whoever is creating the guide listings - do they understand how PVR's work and how they match on names - you just cant go willy nilly and change things - its just going to upset people.... Do your guide makers actually use any kind of PVR with an EPG ? If you make a mistake and change something - let people know about it, just dont change it and not say anything.

Now - luckily, I caught this one in time, and have subsequently set up another series recording, so next Monday the show will record, but does it mean that the following week I need to check it, in case someone has decided to call it "(US) - Vanished" ?

Previous threads on the boards here have discussed some past silly names like - "Dancing with the stars (new series)", and comments about next year, will that be "Dancing with the stars (newer new series)"... Although said in jest, it just highlights the immaturaity of creating guide data. In these threads it was pointed out that although it was a bad name, dont change it, because we are all using it... And it stayed for the whole season like this...

This week, I have found two errors in guide data, without even looking - I am disapointed in the quality of data and lack of checking for a paid service, and basically not happy about it.

I just dont know how vigilant I am going to have to be to check every series recording I have set up - defeating the purpose of it all....


NOTICE TO ALL - If your interested in Vanished, check your settings to ensure it gets recorded properly next week....


Arrrghhhhhhhhhhh

[Jason W]

I would have hoped that since this had been raised at least once before that it would have been resolved. I guess not.

Can we have an official reply on this? The whole point of this guide is for machine consumptions. If the data isn't consistent, it makes it somewhat difficult.

Jason

[martymonster]

When I set up the PVR to record something at say 20:30 for 65 minutes on CH x every Monday.
It gets recorded every week because my Topfields record programs based on date and time, not program names.

Guess that is because I do not use the Taps that you use.
;D

I also spend a few minutes each week checking the guide to see if there is something different to record or whether the times have changed etc.

I find this much more reliable.

(I use IceGuide and ToppyPC only)

[impact]

Yep - people will walk and go back to free semi-non legal versions of guide data again if the consistency is not there...

Jason W - Totally agree... and we definately need comment but assurances that processes are changing or have changed to prevent the continnual onslaught of changes...

martymonster - thats fine, and thats the way the toppy works... more advanced functionality is available with other systems thus allowing you to do the programming by name - thus when the show moves timeslot you do not need to worry about it... Yep we can also record like a VCR but thats so 1980's lol !!!

[mtb]

Due to the way that Ice data is collated (i.e. manually enter by people, not computer), until the stations provide consistant data themselves in an electronic form, there will always be the opportunity for errors.  While I agree that inconsistancies are annoying, consider how someone entering the data who doesn't watch a particular programme could be certain of the correct title/details to use if the data source they get the data from is equally inconsistant.  These are the same poor titles that appear in the TV Guides and papers.

This manual collation of data is a highly intensive, repetative and boring manual task and to increase the number of people checking the data to reduce such problems would undoubtedly increase the cost of the service and undermine its financial viability.  I work in I.T. and, believe me, ALL data entry IS prone to errors. 

Personally I think that Ice do a remarkable job, given that there are seven or so channels of data, 24/7, with all the regional variations from a varienty of sources - as a percentage of that, the number of errors are very small.  They also have to operate within tighter financial constraints that they ought, due to the Channel Nein farce.  I say Nice One IceTV!

Jason W, I cannot agree that the guide is only for machine consumption - we used our Toppy for quite a while with Ice and the EPG only and simply browsed for the programmes we wanted, the main guide data is for human consumption as well.

As it happens, since I now use TED/S to process the data I would not have been impacted by either of the problems you have given, since I would have searched for "vanished" and/or "dancing with the stars" - both would have been found and timers set accordingly (if we watched either of them).  Despite the functionality of TED/S, however, I do still check the future timers and EPG on a fairly daily basis as I acknowledge that the data might not be perfect - but then, I've seen errors in the Now and Next data the stations provide themselves so that's nothing new.

Perhaps you should both have a look at TED/S as a cheap way of complementing the Ice data and providing a far higher level of confidence that your desired programmes will get recorded.

[impact]

TED/s whats that ? It has no impact on people running MCE / Vista. MCE / Vista integrates within Icetv data and there is no possibility of interacting or changing the data.

Yes I work in IT too.... and although I hate the QA people and testers because they make my life hard - they serve a purpose, to ensure quality of systems and data meet user expectations and deliver the quality of service required. In this case mentioned - Vanished - QA is non existant.

Yes errors occur in data entry, but you build systems to reduce or alert to these circumstances... Now take for instance someone typing in Vanished, any good IT data entry system would also see Vanished US and alert the operator to make sure that what they wanted to do was correct, or at least a report published before publication to highlight what was different from last week to the current week - so that a supervisor can sign off on it for publishing - thus reducing the implications of crap data.

In the case of icetv - do you really think that each day they type in the whole programming guide for all channels manually each time - no... They basically push a  button which takes the data from last week, presents it to the scheduler, who then updates the changes. The scheduler in this instance appears to not understand the basics of how pvr's operate and the consequences of making changes. We can assume that this button - copy process exists, based upon the evidence presented in the ch9 court case, where icetv stated that all programming was derived by one guy watching tv constantly for 3 weeks, and they update the guide changes each week from this.

So no QA was performed by another operator, or if so was poorly done. Yes it was a bad choice of name for the first showing of this series, it was known it was a series, as investigation by whatever method icetv choose obtained the synopsis of the episode, and full textual description was derived. The mistake was made the following week in typing a new name and not using the existing one (bad or not) - or at least not notifying the community that it was done.

The same thing occurs occassionally with the ABCTV data - one day in a week it turns out to be differing programming for an hour to two... Why when changes occur is it not investigated slightly or given to a differing person as a check to its accuracy.

[mtb]

Ok, so you're unable to use TED/S, it doesn't change the facts relating to the validity of the content.

In this case mentioned - Vanished - QA is non existant.

Given the fact that the networks love to change timeslot/day/week!/duration/title themselves from week to week, I should truly love to see how you would specify the validation algorithm of content for a particular timeslot.  Whether reported to the data entry operator or to a summary report at the end is irrelevant, the validation processing of such items would be identical - the only difference is if it is in-process or post-process.  Bearing in mind that you could not rely on previous weeks, times, durations or other attributes of the title or program details to accurately extrapolate a valid lookup-set to match against since the networks love to move days and times, change seasons (and therefore titles), drop mid-season, miss a week and double up slots.

To produce such an almost heuristic matching would require significant development time and money, things Ice has neither of in abundant supply, you also have to ensure that the speed of operation of the data entry system does not become so impeded by the validation routines that it impairs the data entry operation - a fine balance to attain and one few manage to properly achieve.  Post processing simply shifts the effort but doesn't reduce it

Consider the programme "Survivor" which contains varying elements in the title from season to season (locations, I think).  Are you suggesting that this valid component of the title be dropped?  To do so would make the data more inaccurate than accurate since you would be unable to distinguish between different series/seasons; your "Vanished" example is effectively the same thing - you again expect the data entry personal to be able to distinguish between the relevant and the irrelevant content of all titles.

I am well aware of the Ice/Nein information and the manner in which the data was originally created, I too have been following the case and reading the blogs and forums.  Nonetheless, given the now larger number of regions and so on, the 'push-a-button copy' process will still have a significant variation each week which must be catered for.  Your idea of having someone sign-off the data?  I'm sure someone already does... but not after reading through all of it, for all channels and regions, even the differences would be significant particularly now we are in the summer silly season when schedules change almost daily!  I'm sure Ice have procedures in place to try to minimise errors as best they can but only within the limitations of their manpower and funding.

By the same token that you consider that Ice could produce or commission such a validation system (given funds they don't have), I would say that it is not impossible to intercept and 'clean/validate' the Ice data en-route to the media centre.  It does, after all, arrive via a known protocol through a known port on the box.  There is no reason why a suitably knowledgable and motivated MCE equiped developer could not simply take that Ice data in on a different box (or perhaps the same), validate and clean it (according to the much smaller requirement set of the individual user) then send it back out in an identical format (to the original) to the media centre. 

Such an approach has been used for years for interfacing between apparently totally incompatible systems, screen scraping was one term for it - during the lead up to Y2K it was commonplace, as it was during the original PC 'revolution' in the 80/90's for interfacing between PC systems and mainframes;  I've done it many times for both scenarios. 

Ice would, I am sure, be very happy to spend their customers' money on developing solutions to validate and verify their data and improve the service they are currently providing.  Unfortunately, the Nein fiasco stopped them from raising the much needed capital for such improvements and instead they must waste it on lawyers.  Given the shoestring they're operating on as a result I think they provide a damned good service for $1.50 a week because, at the end of the day, 90% accurate data would be better than no data at all.

[impact]

IT does not need to be complicated.... even a simple excel spreadsheet would do it - you dont want heuristic lookups or complex things - it just needs to look at simple case sensitive text.

ie. a report that shows differences;

Last week                       This week
ch7
9:30pm Vanished (US)       9:30pm Vanished
Ch9
.....

A simple glance would identify someone has stuffed up on a type - it has got nothing to do with timeslots and last minute changes - someone stuffed up in naming titles and this practice should simply stop ! Fix it - sack the person, change the process, introduce simple checking before publication - do something to fix the ongoing problem.  Its not a costly exercise to do, nor huge, nor time consuming - so Im not interested in the icetv is nearly broke argument, because the reputation of icetv will provide the income later after the courts are all finished - if and only if the data is considered to be trustworthy. Otherwise, alternatives will pop up - people will move to things like free services such as epgstream and then the income completely stops for icetv and epg production.

And as for court cases - no matter what the outcome, either side who losses is likely to appeal - and the process will continue on for another 12 months or more before final resolution.....

You want me to consider survivor... Ok considering it - the title of the show could be Survivor, and subtitle could be Season 10 Fiji - or whatever... I really dont care, so long as the 18 odd episodes of the show remain the same title throughout that season. In fact in this case icetv do indeed do a good job on some things like "The Apprentice", its not called "The Apprentice - Season 5" or "The Apprentice - When donalds hair raises questions" - The show has always remained as "The Apprentice" - and it works well... So well in fact, when ch9 decided to show the latest season at some ghasterdly hour on a Monday night / Tuesday morning - our technology automatically had it set for recording it.... based upon the name showing up! I and many others would have probably missed the first few episodes of the latest season as ch9 did not go out of their way to advertise it, nor was I aware of it, until I saw it being set for recording.

I am unsure if anyone does sign off on the data - and if they do, doubt they are looking for the right things - otherwise the Vanished problem would not occur.

We dont want to start trying to interfere with MCE / icetv interfaces - its a simple setup basically you type in a postcode and thats about it, as for writing a process to cleanse the data in between, yes it could be done, but it would be too awkward for any non technical person to setup and utilise. Plus, from an architectural point of view its the wrong place to fix the data. Truth lies within the ICETV database at present, it should be further upstream but we all know that is never going to happen.

90% accuracy of data is fine, when schedules change at the last moment, unpublished programming changes etc. You will never overcome this, even if TV stations co-operated with a provider. Similarly, breaking news and overruns are the same - the simple thing is you will never get 100% accuracy and to believe you can is just foolish.
However the quality of service suffers with silly mistakes like vanished and abctv over recent weeks - and the thing is they are easily fixed, can be checked quickly to minimise these errors, and will give a better comfort in the accuracy and knowledge of the icetv service.

[mtb]

Im not interested in the icetv is nearly broke argument

Sounds to me like nothing Ice can do, nor anyone else suggests, will satisfy you, you might as well put yourself out of their misery - just ask for a refund on your subscription and use one of those other wonderfully reliable(!) data sources.

[impact]

Well instead of arguing with you - I shall leave it for icetv to comment upon - which was what the post was for....

Your not in a position to make suggestions - you and I both are second guessing on what is going on, and why the problems persist, and you dont understand the MCE interface to icetv or its operation.


All I have said is the problems occur, and it is getting more inconvenient... And from this post and others - I am not the only icetv user who is getting concerned about it.

[Madeleine IceGuide]

Hi

I have started a new topic to respond to this issue and explain what happened.

Thanks

[peteru]

There's more than one way to skin a cat. Perhaps the fault should not be seen with the data, but with the MCE implementation of series recording. Rather than using an exact match, MCE could perform a fuzzy match.

[impact]

Tivo does it the same way
and most other PC based PVR apps as well

Its a problem with the data !

[philzgr8]

I just want to add my support for Impact's assertions here. As an IT person also I am fully aware that there are very simple solutions to prevent this type of problem occurring. It is kind of pointless having the functionality if it can't be trusted and a paid service needs to provide more consistency. I have read Madeleine's explanatory post but it does nothing to properly allay concerns but I guess time will tell.