Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Bug Media Television Hardware

SA Explorer 8000SD/HD Experiences Y2K-like Bug 39

Posted by timothy from the it's-just-like-the-mars-rover dept.
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."
This discussion has been archived. No new comments can be posted.

SA Explorer 8000SD/HD Experiences Y2K-like Bug More

SA Explorer 8000SD/HD Experiences Y2K-like Bug

Comments Filter:
  • i have this model. It's been great otherwise.

  • Graceful Error Handling? (Score:4, Interesting)

    by angst_ridden_hipster ( 23104 ) on Monday February 23, 2004 @10:02PM (#8369287) Homepage Journal
    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).
    • If Year % 4 == 0 Then
      Leap Year
      Else
      Not Leap Year

      Very simple in my opinion.

      • Re:Graceful Error Handling? (Score:4, Insightful)

        by Anonymous Coward on Monday February 23, 2004 @11:10PM (#8369846)
        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

        • 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.

          • Re:Graceful Error Handling? (Score:5, Insightful)

            by DAldredge ( 2353 ) <SlashdotEmail@GMail.Com> on Tuesday February 24, 2004 @12:22AM (#8370364) Journal
            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.
            • 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.
          • 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 ca

      • Re:Graceful Error Handling? (Score:4, Informative)

        by TwoStep ( 36482 ) on Monday February 23, 2004 @11:37PM (#8370042) Homepage
        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()
    • 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.

  • SARA VS Pioneer Passport (Score:4, Informative)

    by Gangis ( 310282 ) on Monday February 23, 2004 @10:25PM (#8369503) Journal
    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.

  • getting the splinter and missing the 2x4? (Score:5, Insightful)

    by Roman_(ajvvs) ( 722885 ) on Monday February 23, 2004 @10:27PM (#8369515) Journal
    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.

    • Re:getting the splinter and missing the 2x4? (Score:5, Interesting)

      by spitzak ( 4019 ) on Monday February 23, 2004 @10:57PM (#8369749) Homepage
      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.
    • 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.

      • 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

    • 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.
      • 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

  • Y2K? (Score:4, Insightful)

    by CowboyNick ( 612553 ) on Monday February 23, 2004 @11:00PM (#8369769)
    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.

    • Re:Y2K? (Score:3, Informative)

      by metamatic ( 202216 )
      Both this bug and Y2K were caused by placing inappropriate range constraints on components of a calendar date.
  • 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 wai

    • Off-topic anecdote (Score:2, Interesting)

      by notsoclever ( 748131 )
      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

  • Mine was fixed quickly (Score:4, Informative)

    by slothman32 ( 629113 ) <pjohnjackson@gmail. c o m> on Monday February 23, 2004 @11:35PM (#8370026) Homepage Journal
    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 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?
  • 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, rep
    • 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.
  • This box is the one Rogers is using here in Ontario. My unit is also affected.

Slashdot Top Deals

The Tao is like a glob pattern: used but never used up. It is like the extern void: filled with infinite possibilities.

Close