Social Feed

I would argue that the fault doesn't completely lie with the guide provider.
The DVR software could do a better job as well.
To me a "new" episode should mean: the episode is new to you, and not: the episode is new to the world.
If it behaved like that, the original air date on the guide wouldn't have mattered.

As a programmer I find that sort of thing a bit annoying since I know how relatively easy that should be to implement.
Given proper indexing on a table that lists the viewed episodes for a show, it should have a negligible performance impact when applying a new/old status column to all the shows in the guide when updating it with new data.
Of course as a developer I also know what it's like to be so overworked and understaffed that there is no time for something this simple (or something even simpler for that matter, like being able to sort the recordings by original air date/episode number).

Does the 922 have any changes in how this functions?

ESPNSTI said:

I would argue that the fault doesn't completely lie with the guide provider.
The DVR software could do a better job as well.
To me a "new" episode should mean: the episode is new to you, and not: the episode is new to the world.
If it behaved like that, the original air date on the guide wouldn't have mattered.

As a programmer I find that sort of thing a bit annoying since I know how relatively easy that should be to implement.
Given proper indexing on a table that lists the viewed episodes for a show, it should have a negligible performance impact when applying a new/old status column to all the shows in the guide when updating it with new data.
Of course as a developer I also know what it's like to be so overworked and understaffed that there is no time for something this simple (or something even simpler for that matter, like being able to sort the recordings by original air date/episode number).

Does the 922 have any changes in how this functions?

Click to expand...

IF the guide provider, Tribune/Zap2It doesn't provide the proper info the "timer software" will not be able to operate accurately. The whole FRACKING point is that it is NEW TO THE WORLD, "the first time shown" or "newly" broadcast. Even if rebroadcasted later that same day/evening. That episode is new to the series until the next one comes along. Otherwise the "new" option would be a moot point and we would need to set up timers daily to catch the shows we want that are "newly" broadcast, as far as we know, that they are "new". Which probably would far better than what is happening now with Tribune. The point in having timers with "Name Based Programming" (OF WHICH DISH made a really big deal about) is to grab the episode for us without our intervention or us to have to worry about it? I believe the campaign was "set it and forget it"? Or why bother having timers. This is the whole point of DISH implementing name based recording. I would really like to see, not to ridicule or demean, what you program. I'm just curious as hell as to where you are coming from.

This has to be the dumbest thing I have ever herd here. And I have been accused of saying some dumb, but true, things. Enjoy the Kool-Aid. OH and have some of the purple. It was Jimmie's fav.

SandFarmer, I think you misunderstood what I was proposing, otherwise you wouldn't have had such a violent opposition to it.
Let me try to explain it again, and hopefully, you'll see that this is a superior system.

To me, the key to whether you want to record/view a show is not if it is new to the world.
Rather it is have you seen it before or not.
So in simple, high level terms, what I'm proposing is this:For example, I didn't start watching the show "Pawn Stars" until earlier last year, for arguments sake let's say it was 08/01/2010.
Now in the current system, if I want to see the episodes from before and after 08/01/2010, I needed to set the timer using the "all episodes" option. If I used "new episodes", I obviously wouldn't see any of the ones from before 08/01/2010.
Now the problem with the current system is that it records episodes regardless of whether or not you've seen them before.
For example, after 08/01/2010, the first time the 06/28/2010 episode aired, it would record it and I would watch it, fine that is what I want. But then any subsequent time the 06/28/2010 episode is re-aired, it again tries to record it, and no I don't want that at all, I've already seen it.
What I propose is the following: I set up the timer to "new episodes" on 08/01/2010.
The first time the 06/28/2010 episode is aired after 08/01/2010, the system sees that I haven't seen it before and marks it as "new" and records it. When I watch that episode, the system keeps a note of that.
The next time the 06/28/2010 episode is re-aired, the system sees that you've already seen it (or sees that it wasn't viewed, but still on the hard drive) and marks it as "old" and does not record it.

Now let's see what that looks like in the Caprica scenario:
In the current system, I have my timer set to "new episodes".
The system sees that the original air date of the episode is 11/02/2010, and since it is now 2011, it marks it as "old" and doesn't record it.
In my proposed system, the system sees that I haven't watched this episode before, it doesn't care about the original air date and marks it as "new" and records it.

The only problem I can see with the system I propose is if you see episodes outside of Dish.
For example, you have seen season 1 - 6 of Smallville on DVD and you then set up a timer to be able to see season 7 and later on Dish.
The timer would still consider episodes from season 1-6 as new in that case.
However, this is easily solved by providing a feature to be able to mark episodes from before a certain air date or episode number as already seen.

SandFarmer said:

IF the guide provider, Tribune/Zap2It doesn't provide the proper info the "timer software" will not be able to operate accurately.

Click to expand...

With the current system, yes, but with my proposed system, in this particular scenario it would be resistent to this problem.
But granted, any system can break down if the data is flawed enough.

SandFarmer said:

The whole FRACKING point is that it is NEW TO THE WORLD, "the first time shown" or "newly" broadcast.

Click to expand...

On this, I disagree with you, as explained above, the point is if you have seen it before or not.
Technically, the Caprica episodes were not new to the world as they were aired in Canada, so from some twisted perspective, the guide data was actually correct.
However, I agree that the guide provider should tailor the data to its customer (Dish) and take original air date to mean the date that it was originally aired on a channel available on Dish.

SandFarmer said:

Even if rebroadcasted later that same day/evening. That episode is new to the series until the next one comes along. Otherwise the "new" option would be a moot point and we would need to set up timers daily to catch the shows we want that are "newly" broadcast, as far as we know, that they are "new". Which probably would far better than what is happening now with Tribune. The point in having timers with "Name Based Programming" (OF WHICH DISH made a really big deal about) is to grab the episode for us without our intervention or us to have to worry about it? I believe the campaign was "set it and forget it"? Or why bother having timers. This is the whole point of DISH implementing name based recording.

Click to expand...

I'm really trying but I have a hard time trying to follow what you're saying here.
I think you're implying that what I propose will cause a lot more manual maintenance of timers and events.
That however is not the case, in fact it will reduce the required maintenance and add some resilience to bad guide data.

SandFarmer said:

I would really like to see, not to ridicule or demean, what you program. I'm just curious as hell as to where you are coming from.

This has to be the dumbest thing I have ever herd here. And I have been accused of saying some dumb, but true, things. Enjoy the Kool-Aid. OH and have some of the purple. It was Jimmie's fav.

Click to expand...

Mate, I'm no rookie when it comes to programming (Close to 30 years of experience), but that doesn't mean I can't be wrong or make mistakes (and I would have no problems if being called out on them).
But in this case I know I'm not wrong here, and my proposed system makes more sense than the current one.

ESPNSTI said:

SandFarmer, I think you misunderstood what I was proposing, otherwise you wouldn't have had such a violent opposition to it.
Let me try to explain it again, and hopefully, you'll see that this is a superior system . . .

Click to expand...

ESPNSTI, I fully understand what you are saying. Your solution is based on personal/engineers preference/point of view, which may not entirely be a superior product. Where it would have to make the software more intelligent than it already is, and be mostly perception. It's having a hard enough time now without trying to place Boolean actions in it. I could only imagine the TiVoesque (another law suit brewing here) GUI. You are designing for the flaws of a provider to make your product "functional". When in all reality you should pick a more accurate provider. Even then I doubt that yours would operate properly if the guide data was as all over the place as Tribune is. The simple solution would be fix the data. The real problem is that the guide info/data is flawed and has been for years and if it were corrected all would be fine and there would be no need for a "new solution". I have been tracking idiosyncrasies for years and DISH will no longer discuss it even though I was hired, by DISH, at one time to redesign and fix it. They never went ahead with it. The "Name Based Recording" is not that with out the guide data being correct. And if it were there would be no need for your "proposed system", this conversation, or even this thread. The one in place would work just fine, IF the guide data was as correct as it should be by all rights and realities. After all, when you look at it, we're the ones paying, in many ways, for the inaccurate data.

I was the Project Manager for a private development firm working with AT&T that developed a Police and Fire Dispatch System, that was later turned into what is now the 911/E911 system. And have been designing and installing custom home theaters and recording studios since my roadie days. I know what it is like to wrangle software design engineers (programmers) and that they tend NOT to think out of the "common genre box" in creativity, but over think and design the task at hand. After all of this exposure I went into project design/end publishing, where I was able to interpret what was needed by the end-user to the engineers (such as we are "discussing" here, somewhat), watchdog them so that they at least colored within the lines and then once they were done evaluate the project to assure that it met the intent criteria making sure the software preform as it was intended to do, and then write the user instructions in a manner that the end-user would understand them. Basically translate from human-to-engineer-to-human. So I have a bit of street creds myself. Thus my "violent" opposition to your plan. Especially when all it would take is for the one that is in place to work is for the baseline data to be correct to fix the issues at hand. Which in turn would require an accurate provider (not Tribune/Zap2It) and astute subscriber (DISH). The current software is solid and only needs accurate data to function properly. The fact that this is not the case is the point of the problem.

Thank you for playing. I'm done.
. . . sf

SandFarmer said:

ESPNSTI, I fully understand what you are saying. Your solution is based on personal/engineers preference/point of view, which may not entirely be a superior product. Where it would have to make the software more intelligent than it already is, and be mostly perception. It's having a hard enough time now without trying to place Boolean actions in it.

Click to expand...

You're kidding right? This would be an utterly simple addition.
Furthermore, it would NOT touch one of the most critical areas of the software directly (scheduling), it would simply provide a different way to generate the new/old status data of an episode to the scheduling engine.

A unique internal identifier for the TV show and a unique internal identifier for the episode is all you need in a Show_Episodes_Watched table. I can't imagine that those identifiers don't already exist in the guide data.

If you see that a show has been watched more than a certain percentage (say 90% for example), you add it to the Show_Episodes_Watched table. Judging from Dish Remote Access, the amount a show has been watched is already available for recordings at least. You could apply this logic to TV watched live as well as opposed to watching recordings, but I would consider that optional.
FYI, if you want it simpler you could as an alternative track that the show was once recorded regardless if it was actually was viewed or not.
It wouldn't be as slick as tracking if it was watched, but in practical terms, you would probably end up with the same result 99% of the time unless you frequently record things that you don't watch.

When updates to the guide are downloaded, for each episode that is being updated, simply do a lookup in the Show_Episodes_Watched table. If a record is found, mark it as old in the guide, if not, mark it as new.

Tada! There is the core of what I'm proposing.
If a programmer can't add that without screwing up the system, they should be fired on the spot.

SandFarmer said:

I could only imagine the TiVoesque (another law suit brewing here) GUI.

Click to expand...

I'm not familiar with the Tivo GUI, but what GUI changes? The only one needed would be to mark past episodes as viewed in case you saw them outside of Dish, and that could be a very minor addition. You could even consider that optional if you're that bothered by it.

SandFarmer said:

You are designing for the flaws of a provider to make your product "functional". When in all reality you should pick a more accurate provider. Even then I doubt that yours would operate properly if the guide data was as all over the place as Tribune is.
The simple solution would be fix the data. The real problem is that the guide info/data is flawed and has been for years and if it were corrected all would be fine and there would be no need for a "new solution".
I have been tracking idiosyncrasies for years and DISH will no longer discuss it even though I was hired, by DISH, at one time to redesign and fix it. They never went ahead with it. The "Name Based Recording" is not that with out the guide data being correct. And if it were there would be no need for your "proposed system", this conversation, or even this thread. The one in place would work just fine, IF the guide data was as correct as it should be by all rights and realities. After all, when you look at it, we're the ones paying, in many ways, for the inaccurate data.

Click to expand...

Yes obviously it would be better if the guide data was more accurate, I'm not contesting that.
However even with the guide being correct, this is still a better system than the current one.
So, yes, absolutely there is a need for this to address the scenario of catching up on a show: you have seen some old episodes, but not all. Currently, neither the "new episodes" nor "all episodes" option is suited for this.
Quite frankly I had thought of this long before this but did not bother posting it, but this just happens to have the happy side effect of being more resilient against bad guide data.

SandFarmer said:

<long description of a business analyst>. Thus my "violent" opposition to your plan.

Click to expand...

You're a BA, therefore you oppose a programmer's plan? lol, that tells me a lot.
FYI, I work with BA's on a daily basis, and there's a healthy give and take there, sometimes they make suggestions on how to improve my designs, other times I point out a better way to them, and we're all flexible and sensible.
What I proposed is logical and clearly a better system with little if any drawbacks, I know it, and I suspect that you know it as well.

SandFarmer said:

Especially when all it would take is for the one that is in place to work is for the baseline data to be correct to fix the issues at hand. Which in turn would require an accurate provider (not Tribune/Zap2It) and astute subscriber (DISH). The current software is solid and only needs accurate data to function properly. The fact that this is not the case is the point of the problem.

Thank you for playing. I'm done.
. . . sf

Click to expand...

I'm not arguing that the current software doesn't work with correct data.
All I am arguing is that the software could be more resilient to bad data, and that the current system for figuring out what's new versus old is too limited for what a viewer needs.

I believe Dish receivers look at what has been recorded in the last 30 days. So, if you say new or repeats it still looks at what it has recorded over the last 30 days. If guide info is so bad that the first run date and episode info is missing they tend to just record it just in case.

I missed this thread. My DVR recorded the last 3 episodes of Caprica. I didn't even notice until I started watching one and hadn't seen any of the "Previously on Caprica" stuff. I decided to go ahead and watch them without the 2 missing ones. I figured out what's going on. It's not the best show in the world anyway, but I've watched this far, so I might as well finish it.

Also, I did check on Merlin in time and was able to restore Friday night's timer so I did record the season premiere.

mike123abc said:

I believe Dish receivers look at what has been recorded in the last 30 days. So, if you say new or repeats it still looks at what it has recorded over the last 30 days. If guide info is so bad that the first run date and episode info is missing they tend to just record it just in case.

Click to expand...

this is true but for some reason it still didn't schedule Merlin to DVR,