I tried to record Haven on SYFY I set for new episode but it record all. SYFY has the same one several times a week.
722 & 722k recording all episodes
- Thread starter Trek2000
- Start date
- Latest activity Latest activity:
- Replies 17
- Views 2K
first i would check your timer to be sure it is not set to record all. if it is set to record new and it is recording all shows i would look at the guide info and see if it doesn't show a "first aired date". the default in the software records all if it is missing that piece of guide info. it does this just incase it is a new episode and doesn't have the date. i just searched for haven and set a timer for new episodes and it set each one to record. the encore shows are the ones without that first aired date problem. Tribune Media Services is where dish gets it's guide data and they do a half-@$$ed job a lot of times.
You're not the only one having this problem. It just started last week.
The episodes are "replays" but being seen as "new" the only differences between the listings as us users see it, is the bottom of the episode info where it shows Episode: XX Original Air Date: 09-16-11 where as the repeat says Episode: XX Year: N/A ... in the example the XX would be the real episode number. and it literally has "Year: N/A"
Started a thread on this over at DishSupport .. and I"ve deleted the timer and created again and it did the same thing.
Just looked at today's schedule for Haven. Episode 22 is on with a 1st air date of 9/16/2011 at 10PM edt. 2 hgours later it is repeated, but this time it says Year N/A. Without the air date, it will also be recorded. This is not a Dish problem but Tribune Media's problem. They supply all the info for the epg.
Your best bet is to manually skip the repeat programs. It's very simple. Press the dvr button 3 times. Left arrow over to the list of scheduled recordings. Arrow down to the repeated episode and press Info. Arrow up to Skip and select that. Then press Cancel and continue to arrow down to check for other repeat episodes that are scheduled to repeat. If you see a program that is X'd out, but you want to record it. Reverse the procedure and select Restore.
I often use this feature when I have a conflict and one of the conflicting shows is being repeated later. If I select Skip, it will change the later scheduled showing to change from Skip to Record automatically.
I often use this feature when I have a conflict and one of the conflicting shows is being repeated later. If I select Skip, it will change the later scheduled showing to change from Skip to Record automatically.
Its not a problem of how to circumvent the duplicates (most of us already know how to)... but that they *are* now happening and should *not* be.
DISH IRT needs to file an engineering report, requesting that Tribune clean up/clear up their problems because its effecting multiple users.
DISH IRT needs to file an engineering report, requesting that Tribune clean up/clear up their problems because its effecting multiple users.
It's nothing new. I've seen it happening for years. Others have complained before. I know I have.
amazing that they cant come up with an option to click that says skip the ones with n/a for dates
Of course the failure of correct data causing this type of problem is nothing new..
what *is* new is that its happening right now, we can pin point a spot where the problem is, and "they" need to know... they in this case being the ones that can fix *this* issue.
Will it happen again? I'm sure it will.. but rather than hope it gets caught... or wait for three more weeks of *me* or *you* having to correct this failure by hand.. why not try to alert *them* to it sooner so they can fix it as it happens?
I still haven't seen a report on what caused the 129 outage.. and probably never will... but even with as low of an opinion I have for dish ... it would be stupid for dish *not* to find the cause of the failure ... and if preventable, create a policy/procedure/routine to handle that problem *not* happening again ... at least not by the same cause..
In this duplicate issue, the same thing.. for all we know a computer failed .. someone restored a backup and thought everything was fine.. only this time its effecting Haven (SciFi) .... I'm not nieve enough to think they pay someone just to sit there and look at the data that's flying through .. I *would* believe they pay someone to take a report, and investigate the cause, to see how it can be fixed.
So I'm inclined to chalk this up to "it happens" minor bump that can be corrected if the right person(s) know about it.. and the way to do that.... is for Dish to file the report..
what *is* new is that its happening right now, we can pin point a spot where the problem is, and "they" need to know... they in this case being the ones that can fix *this* issue.
Will it happen again? I'm sure it will.. but rather than hope it gets caught... or wait for three more weeks of *me* or *you* having to correct this failure by hand.. why not try to alert *them* to it sooner so they can fix it as it happens?
I still haven't seen a report on what caused the 129 outage.. and probably never will... but even with as low of an opinion I have for dish ... it would be stupid for dish *not* to find the cause of the failure ... and if preventable, create a policy/procedure/routine to handle that problem *not* happening again ... at least not by the same cause..
In this duplicate issue, the same thing.. for all we know a computer failed .. someone restored a backup and thought everything was fine.. only this time its effecting Haven (SciFi) .... I'm not nieve enough to think they pay someone just to sit there and look at the data that's flying through .. I *would* believe they pay someone to take a report, and investigate the cause, to see how it can be fixed.
So I'm inclined to chalk this up to "it happens" minor bump that can be corrected if the right person(s) know about it.. and the way to do that.... is for Dish to file the report..
How did you miss it? It was Human Error. There is nothing E* can do about what SES does, E* doesn't control the bird. I still will lay odds it was someone that told the sat to go into maintenance mode and it did it. That basically shut down everything on board and reboots. Not a smart thing to do to a bird already in orbit.
Not going to either. The thought is better to record than to possibly miss an episode.
what human error? "what does this button do?" "hey charlie ... watch this!" etc... While Dish doesn't necessarily control the satellite, you can bet they are demanding that SES prevent that type of human error.. etc.. in turn, SES would be looking at the issue, and would then be the one responsible for the policy, procedure, etc.. so that this doesn't happen again... concept still applies.
Same of the data issue ... for all we know John Q got sick last week and his replacement doesn't know what the hell he's doing ... an Tribune will not know there is a problem (today, last week, next month) without getting a report filed saying "Hey.. your data is wonky for X" And to think that filing such a report is fruitless is wrong. Its the type of issue that can happen and probably will ... but we would hope that by filing, they would correct as much as possible "when John Q is out sick, this is the checklist to follow..."
Tech support blames the guide for this and similar problems. Instead of just going by the episode # or original air date, it also looks at description. It does this on soccer games I record. It sees the word NEW and thinks it is a different entry than the repeat.
It is a guide problem that Dish has no control over. Tribune Media supplies the info for the guide. If they supply garbage that will foul up the timers. This has been repeatedly discussed.
and I'm not sure that what the tech told you is true ... its possible, but highly unlikely ... because there are times that the description has said new, and the event *wasn't* marked for record on my end.. as well as the word "New" popping up inside the description .. "Peter gets a new car" would potentially trigger..
I just assumed it was some form of "flag" like a bit set in the specific order of data .... 11010 - not new .... 11011 -- is new ... like in binary data ... or like the flag when you get email for "important" or "low priority" etc etc etc..
