Slashdot Mirror


SA Explorer 8000SD/HD Experiences Y2K-like Bug

An anonymous reader writes "According to an article at Audioholics, a firmware bug was just discovered in the Scientific Atlanta 8000SD and 8000HD DVRs (Digital Video Recorders) which renders them unable to record. This firmware bug was discovered when the units attempted to recognize February 29th on the programming guide. The units are apparently unable to recognize this date, and as a result, shut down all record functions. All other aspects of the 8000 will continue to work. So far, it looks like no previously recorded material was lost. Scientific Atlanta is apparently in "Emergency Session" working on a software patch. The problem began occuring on the 23rd when the 7-day program guide first began to encounter the February 29th programming."

39 comments

  1. BOOO by servicepack158 · · Score: 1

    i have this model. It's been great otherwise.

  2. Graceful Error Handling? by angst_ridden_hipster · · Score: 3, Interesting

    To quote a widely-used software development guideline document*:

    "Well-written applications include error-handling code that allows them to recover gracefully from unexpected errors. When an error occurs, the application may need to request user intervention, or it may be able to recover on its own. In extreme cases, the application may log the user off or shut down the system."

    Now, I figure encountering a nonexistent date may well qualify as an "extreme case." Still, a developer might want to at least think a bit about calendars before qualifying February 29th as nonexistent.

    (* It's from a Microsoft Developer Guideline. I put that as a note, since if I started with it, I'd be suspected of troling).

    --
    Eloi, Eloi, lema sabachtani?
    www.fogbound.net
    1. Re:Graceful Error Handling? by BoomerSooner · · Score: 0

      If Year % 4 == 0 Then
      Leap Year
      Else
      Not Leap Year

      Very simple in my opinion.

    2. Re:Graceful Error Handling? by Anonymous Coward · · Score: 4, Insightful
      Very simple in my opinion.

      Simple, and wrong. The full rules are as follows:

      if year % 400 == 0: leap year
      else if year % 100 == 0: not leap year
      else if year % 4 == 0: leap year
      else: not leap year

    3. Re:Graceful Error Handling? by BoomerSooner · · Score: 2, Funny

      If it works for the next 24 years I'll be retired and they can hire someone else to fix it. I'm certain my code will not be around in 2100. So for all "practical" purposes, year % 4 = 0 works for the next 90 or so years.

    4. Re:Graceful Error Handling? by TwoStep · · Score: 3, Informative

      If you do this, you will have problems in 2100. It should be:

      if ((year % 4 == 0) && ((year % 100 != 0) || (year % 400 == 0))
      LeapYear()
      else
      NotLeapYear()

      --
      There are 10 different types of people in this world... those who understand binary, and those who don't.
    5. Re:Graceful Error Handling? by DAldredge · · Score: 4, Insightful

      That is what every cobal programmer said. Guess what, they where wrong and so are you.

      Please stop programmer if you are unable to think about the results of your actions.

    6. Re:Graceful Error Handling? by slothman32 · · Score: 2, Insightful

      Mine didn't work but the error handling was great. Unlike some apps or even firmware that crash on error this just simply didn't work. It still let you watch both regular TV and recorded shows and even had the usual DVR features still present except recording. It didn't say why it didn't work but it didn't crash.

      --
      Why don't you guys have friends or journals?
    7. Re:Graceful Error Handling? by Anonymous Coward · · Score: 0

      ...Please stop programmer if you are unable...

      Ummmm.....no, that's too easy. :)

    8. Re:Graceful Error Handling? by Haeleth · · Score: 1

      If you do this, you will have problems in 2100.

      Um, I doubt he'll be the one having problems...

    9. Re:Graceful Error Handling? by Anonymous Coward · · Score: 0

      Learn to spell you illiterate fool. You didn't even spell COBOL properly.

    10. Re:Graceful Error Handling? by BoomerSooner · · Score: 1

      A PC Based Web System is not even comparable to the Mainframe (CICS/COBOL) systems of yore. Most projects my company implements are reworked every 4-5 years out of necessity. To stay ahead of the market you should plan for what is needed now, not what "might" be needed in 90 years.

      I guess getting a project done in a timely manner is important to my company. Plus our data specs in my primary field change every 5-10 years so we have no choice but to rewrite. Forced obsolescence is a good thing.

    11. Re:Graceful Error Handling? by Anonymous Coward · · Score: 0

      I'd just like to point out that in this case, we're talking about TWO EXTRA FUCKING LINES OF CODE.

    12. Re:Graceful Error Handling? by GlassHeart · · Score: 1
      If it works for the next 24 years I'll be retired and they can hire someone else to fix it. I'm certain my code will not be around in 2100. So for all "practical" purposes, year % 4 = 0 works for the next 90 or so years.

      I thought you were joking until I read your follow-up.

      It's not a problem if your function will never be called with anything but the current year. However, how can you guarantee that no other programmer would ever call your function with some other year, and get the wrong answer?

      You can put in an:

      assert(year > 2000 && year < 2100);
      to ensure that, and a comment to explain why it only works in this case. Alternatively, you can define your function as:
      int is_leap_year_2000_to_2100(int year)
      which is of course a weaker guarantee than the assertion, but should still intrigue the caller enough to check your code.

      But the problem is that you're avoiding the two lines of code to be lazy, which means you'll probably not want to do either. Instead, you'll probably end up lying in the function name:

      int is_leap_year(int year)
      and introduce a bug that will definitely take longer to debug than it takes for you to write and test 2 lines of code.

      To knowingly do that is plainly unprofessional.

  3. SARA VS Pioneer Passport by Gangis · · Score: 3, Informative

    I have the 8000 model, and it runs Pioneer Passport ECHO software, from Brighthouse Central Florida. From what I've been hearing on the SA8000 mailing list, this type of issue only affects those loaded with SARA software. The Passport software has some issues, where it won't display the showings for Sunday in the guide (it just skips from Sat to Mon.)

    No word on if they're going to fix that for the Passport models as well.

    --
    "Black holes are where God divided by zero." - Steve Wright
  4. getting the splinter and missing the 2x4? by Roman_(ajvvs) · · Score: 5, Insightful
    That's just piss poor programming. Honestly, If you can't figure out that knowing about and handling leap years is important in software that schedules, then maybe outsourcing your position is fitting...

    I recall I had a whole discussion with my friends about whether 2000 had a leap year. Most of those who got it wrong weren't the most computer literate, but it took about 5 minutes to figure it out from the internet.

    It's needless bugs like this, which give programmers a bad name.

    --
    click-clack, front and back. I'm not moving this car otherwise.
    1. Re:getting the splinter and missing the 2x4? by spitzak · · Score: 5, Interesting

      Actually the weird thing about getting 2000 wrong (it *IS* a leap year) is that it requires more research to actually get it wrong. A very simple approach would get it right.

      In order of complexity leap year algorithims are:

      0. No year is a leap year (2000 is wrong)
      1. All years where n%4==0 are leap years (2000 is right)
      2. Except when n%100==0 (2000 is wrong)
      3. Except when n%400==0 (2000 is right)

      For some reason a huge number of people are at aware of the rules up through #2 above, even though knowing only #1 would make the results more correct.

    2. Re:getting the splinter and missing the 2x4? by CowboyNick · · Score: 5, Funny

      Top x reasons you've been coding to much:

      ......
      2. You start all lists with "0".
      .....

      --
      -CowboyNick
    3. Re:getting the splinter and missing the 2x4? by spitzak · · Score: 1

      Actually I started at 1 and realized that I had skipped the "0" case and inserted it after typing the message.

    4. Re:getting the splinter and missing the 2x4? by cerberusss · · Score: 2, Insightful
      If you can't figure out that knowing about and handling leap years is important in software that schedules, then maybe outsourcing your position is fitting...

      That's a bit harsh. I thought I was among fellow geeks here. How do you know it was a programmer mistake? Maybe this company had some manager which was harassing the programmer to finish his work. I've had a few confrontations myself, and it's definitely not always to blame on the programmer.

      --
      8 of 13 people found this answer helpful. Did you?
    5. Re:getting the splinter and missing the 2x4? by Roman_(ajvvs) · · Score: 2, Insightful
      That's a fair call. But what you're giving is still just an excuse for poor programming. I know first hand as well that things get rushed. In your example, It'd hopefully be the manager being held to account since he's the one responsible for the programmer.

      Getting the right date and having enough space are two very common issues that programmers have to deal with. If this was some obscure button press or recording combination error, then I'd be "yeah.. that's not entirely the developers' fault", but when it comes to not recognizing a date, I find it just that bit harder to be sympathetic.

      --
      click-clack, front and back. I'm not moving this car otherwise.
    6. Re:getting the splinter and missing the 2x4? by SpaceLifeForm · · Score: 1

      How do you know that the position wasn't outsourced? To say that whomever programmed it (with the bug) should lose their job to outsourcing is typical management speak - sickening.

      --
      You are being MICROattacked, from various angles, in a SOFT manner.
    7. Re:getting the splinter and missing the 2x4? by Anonymous Coward · · Score: 0

      Here here! Leap year testing should be part of ANY (let me repeat that *A*N*Y*) software test plan where the program in question deals with dates OF ANY KIND.

    8. Re:getting the splinter and missing the 2x4? by Roman_(ajvvs) · · Score: 1
      I don't know. But just so you know, I never said the programmer should be outsourced, just the person who didn't understand basic date/time handling concepts (and that could very well be the pointy haired fellow ;). I used the term 'outsourcing' very loosely and possibly somewhat in a sarcastic fashion in my original comment.

      What are the first three(3) things you think of when you have to handle a date in a system? for me it's:

      • What platform(s) am I running on?
        This answer determines what I have to work with, what the underlying OS takes care of for me and what I need to do for myself. Things like the maximum date recognizable (Y2K is an extension of this), Date Formatting (internationalization), how a date is stored.
      • What is the effect of date variations ?
        Variations are things like setting the clock back, leap years, duration calculations, crossing the 24:00-00:00 boundary.
      • How critical is getting the date right?
        Scheduling systems need accurate dates and times. FSA'a often don't care about date, but usually more about time.
      Would you forget about leap years designing an atomic clock? How about a simple calendar for your palmtop?
      --
      click-clack, front and back. I'm not moving this car otherwise.
  5. Y2K? by CowboyNick · · Score: 4, Insightful

    How is this a Y2K-like bug? This seems more like a date calculation bug. Before you flame, I understand that Y2K bugs were date realted also, but this is not related to the end of a millennium, more like the calculation of a leap year.

    --
    -CowboyNick
    1. Re:Y2K? by metamatic · · Score: 2, Informative

      Both this bug and Y2K were caused by placing inappropriate range constraints on components of a calendar date.

      --
      GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
  6. Might explain a few things... by jpdbest · · Score: 2, Insightful

    I only just got one of these (Explorer 8000) last Friday. In the few days I've had it, it's been doing some really quirky things with the scheduled recordings. After having this only for four days, I've gotten in the habit of double-checking my recording schedules since on more than one occasion I've noticed the times or the programs have changed. That, or it refuses to save some (but not all) schedules if certain recording options are used. I don't know if this bug is cause of the problem, but I'll wait until after Feb. 29th to see if it starts behaving better. More likely buggy code...

    It's sad that this Y2K bug wasn't caught. And make no doubt, this *is* a Y2K bug. In one of the companies I worked for, the Y2K date testing started with Sept. 9, 1999 (9999 - some programs used four nines as a exit/quit/terminate), with dates right through to Feb. 29th, 2004.

  7. Mine was fixed quickly by slothman32 · · Score: 4, Informative

    Hey I have that. I was watching TV yesterday it it wouldn't record. I pressed the button then select, it right away went back to the guide or show. Manual recording did work though. Luckely TW "rebooted" my machine for me and it works fine now. I didn't even think that it was a "y2k" or feb 29th issue thou it did start just before the end of Sunday. Regardless of what you say about TW or other big companies it was fixed within 24 hours of the problem. And it still worked mostly before that.

    --
    Why don't you guys have friends or journals?
  8. Off-topic anecdote by notsoclever · · Score: 2, Interesting
    Once upon a time (1997 or so) I worked in my university's data center, performing reporting queries for various departments. One of these queries was for determining who should get a mailing for a scholarship, which required that the students graduated high school after May 1996.

    So, I did something like

    SELECT * FROM student_table WHERE hs_grad_date > '05/01/1996';
    and it spat out a whole bunch of rows, and I was about to send off the results as "complete," until suddenly I noticed quite a few entries for people who has graduated from the university in the 1970s.

    So I looked more closely at the various columns, and noticed that quite a few of them had a graduation date of 09/09/1999 and that the field indicating that they had gotten a GED instead of graduating normally was filled.

    Apparently, back then the database server they had didn't allow a field to remain blank (since it was all legacy which had been migrated between at least a half a dozen architectures by the time I'd had any part in it), so of course if there was no information available they just put in 9/9/99.

    I bet that when the report was run in 2000, a lot of students who had already gotten their degrees decades before were quite surprised to get a mailing informing them that they had qualified for the scholarship!

    --
    There are 10 kinds of people: ones who understand ternary, ones who don't, and ones who think this joke is about binary
  9. Leave it to Time Warner... by unitron · · Score: 1

    Why does it not surprise me that of all the OEMs they could have gone with, TW cable manages to pick the one that's going to have technical problems?

    --

    I see even classic Slashdot is now pretty much unusable on dial up anymore.

    1. Re:Leave it to Time Warner... by schergr · · Score: 1

      I have this box on TWC in NYC and haven't had any trouble so far.

  10. Aahhhh... by Skater · · Score: 1

    So this explains the odd behavior of mine yesterday. The display showed it counting down in hex digits, then it put something else on the display (I don't remember what), and it finally reset itself, flashing code 6680 as it usually does when it crashes.

    At the time, I figured Cox was doing a software update to it, but now I find that it's a serious bug.

    Maybe they can make the scheduling a little smarter at the same time, like, say being able to record a certain program only once a week at a set time, repeating weekly. If I want to record the Simpsons on Sunday night, I either have to manually program it every week, or it'll record all Simpsons episodes on each week (the local Fox affiliate plays 3 episodes every weekday), which interferes with other recordings. (After all, VCRs managed this trick two decades ago...)

    --RJ

    1. Re:Aahhhh... by Anonymous Coward · · Score: 0

      get tivo

    2. Re:Aahhhh... by slothman32 · · Score: 1

      Actually I think that is when they were updating it. It happens to mine every once in a while. As for the Simpsons, why don't you want the weekday ones. There is such a thing called a "manual recording." You go to the list of recorded programs and press "preferences." The "scedule a manual recording." You can do a certain time every week there.

      --
      Why don't you guys have friends or journals?
  11. Canadian Rogers customers as well .... by gstoddart · · Score: 1

    This box is the one Rogers is using here in Ontario. My unit is also affected.

    --
    Lost at C:>. Found at C.
  12. If you worked for me, by Anonymous Coward · · Score: 0

    you'd be fired now!

    And yes I do check on that sort of thing.

  13. That's some shitty coding you did there hoss by Anonymous Coward · · Score: 0

    Stop making it hard, you moron. Do you code like that? Don't be such a retard.

    As Pope Gregory put it in 1582 when the decision was actually made:

    "lest the equinox recede from XII calends April [March 21st] in the future, we establish that a bissextile [intercalation day] shall be inserted every four years (as with the present custom), except in centennial years. Those, although they were always bissextile until now, will not be from now on, although we decree that year 1600 is still bissextile; after that, however, those centennial years that follow are not all bissextile, but the first year is, and then three centennial years have no bissextile [intercallation] performed, and, then, the fourth centennial year is indeed bissextile. Thus, the years 1700, 1800 and 1900 will not be bissextile, and then, as with the habit with which we are now accustomed, the year 2000 will have a bissextile intercalation day, as the day February 29, and that the same order of intermittent bissextile intercalations in each four hundred year period will be preserved in perpetuity."

    Your algorithm is as efficient as Gregory's Bull.

    1. Re:That's some shitty coding you did there hoss by PopeGregoryXIII · · Score: 1
      In the original comment I was showing the rules for leap years with psuedo code. In my papal bull I was just showing off my knowledge of the word 'bissextile', did you see how many times I used it?

      Sure you could write the code slightly more efficiently by testing the primary case first and the exceptions inside that. On most runs you would avoid 3 failed cmp ops and the pipeline flush that comes with it, but most developers don't care and don't need to care about that sort of thing. By the time you throw in 50 levels of abstraction and libraries do you really think that making the code any harder to read and gaining a slight level of efficiency is worth it?