PDA

View Full Version : Fixing 6.2a file system on Phillips DSR708R


Imagr8m8
02-21-2008, 10:35 PM
In Dec 07, my DTivo started rebooting all the time. Lots of research suggested bad internal connections, power supply problems, bad drive, etc. I cleaned all the internal connections AND mirrored/installed a new 500GB drive. Still rebooting. I dug out and installed the stock tivo drive and everything works fine....'cept, of course, no wonderful "features" I've come to enjoy. So I'm guessing the file system somehow got messed up on the drive I was using and those problems got transferred to the new drive.

How can I most easily get the newest/biggest drive working without loosing recordings and features that were all working OK?

I have the original Tivo Drive with 6.2a files on it (it works fine in the DTvio)

I have my first replacement 180GB drive (with all my recordings & SPs on it) that seems fine except for the reboots.

I have a brand new 500GB drive (copied from 180GB and then expanded)

I also have 6.2a slices on a PC, serial cable, etc.

Plz let me know if some other info is needed so I can take the next step in resolving this issue intelligently. ;-)

Please correct me if this is wrong...I'm sticking with 6.2a instead of connecting the phone and letting it upgrade to 6.2f because I use Nanvue to move content back and forth and was planning to stream from DTivo->XBMC. But I mostly need to go from DTivo->PC which acts as a media server for the whole house.

Excerpts from my TVErr.log:
Jan 4 19:27:09 (none) TmkAssertionFailure[321]: (Audit, line 31 ())
Jan 4 19:27:09 (none) HandleDataChanged[321]: Tmk Fatal Error: Thread HandleDataChanged <321> strayed!
Jan 4 19:27:09 (none) HandleDataChanged[321]: bt -t /tvbin/tivoapp
Jan 4 19:27:09 (none) HandleDataChanged[321]: read 0x2aaa8000 /lib/ld.so.1
Jan 4 19:27:09 (none) HandleDataChanged[321]: read 0x2ab04000 /lib/libutil.so.1
Jan 4 19:27:09 (none) HandleDataChanged[321]: read 0x2ab48000 /lib/libdl.so.2
Jan 4 19:27:09 (none) HandleDataChanged[321]: read 0x2ab8c000 /lib/libpthread.so.0
Jan 4 19:27:09 (none) HandleDataChanged[321]: read 0x2abe8000 /lib/libm.so.6
Jan 4 19:27:09 (none) HandleDataChanged[321]: read 0x2acb0000 /lib/libc.so.6
Jan 4 19:27:09 (none) HandleDataChanged[321]: 0x01055e38 0x0101cf9c 0x0101cb9c 0x00c65ddc 0x00c6245c 0x00c3f8bc 0x00c3f0c8
Jan 4 19:27:09 (none) HandleDataChanged[321]: 0x00c3e9c4 0x00c6c02c 0x00c6b940 0x00c6b790 0x0123e850 0x013a706c 0x013ce190
Jan 4 19:27:09 (none) HandleDataChanged[321]:
Jan 4 19:27:09 (none) HandleDataChanged[321]: Tmk Fatal Error: Thread HandleDataChanged <321>: assertion failure
Jan 4 19:27:09 (none) HandleDataChanged[321]: Tmk Fatal Error: Thread died due to signal -2
Jan 4 19:27:09 (none) HandleDataChanged[321]: Invoking rule 834: rebooting system
Jan 4 19:40:28 (none) DbGc[312]: saying 3549 isn't garbage 'cuz never visited it!
Jan 4 19:42:17 (none) TmkAssertionFailure[319]: (Audit, line 31 ())
Jan 4 19:42:17 (none) HandleDataChanged[319]: Tmk Fatal Error: Thread HandleDataChanged <319> strayed!
Jan 4 19:42:17 (none) HandleDataChanged[319]: bt -t /tvbin/tivoapp
Jan 4 19:42:17 (none) HandleDataChanged[319]: read 0x2aaa8000 /lib/ld.so.1
Jan 4 19:42:17 (none) HandleDataChanged[319]: read 0x2ab04000 /lib/libutil.so.1
Jan 4 19:42:17 (none) HandleDataChanged[319]: read 0x2ab48000 /lib/libdl.so.2
Jan 4 19:42:17 (none) HandleDataChanged[319]: read 0x2ab8c000 /lib/libpthread.so.0
Jan 4 19:42:17 (none) HandleDataChanged[319]: read 0x2abe8000 /lib/libm.so.6
Jan 4 19:42:17 (none) HandleDataChanged[319]: read 0x2acb0000 /lib/libc.so.6
Jan 4 19:42:17 (none) HandleDataChanged[319]: 0x01055e38 0x0101cf9c 0x0101cb9c 0x00c65ddc 0x00c6245c 0x00c3f8bc 0x00c3f0c8
Jan 4 19:42:17 (none) HandleDataChanged[319]: 0x00c3e9c4 0x00c6c02c 0x00c6b940 0x00c6b790 0x0123e850 0x013a706c 0x013ce190
Jan 4 19:42:17 (none) HandleDataChanged[319]:
Jan 4 19:42:17 (none) HandleDataChanged[319]: Tmk Fatal Error: Thread HandleDataChanged <319>: assertion failure
Jan 4 19:42:17 (none) HandleDataChanged[319]: Tmk Fatal Error: Thread died due to signal -2
Jan 4 19:42:17 (none) HandleDataChanged[319]: Invoking rule 834: rebooting system

whitepelican
02-22-2008, 12:52 AM
I've just recently had the same issue. I was getting reboots every few minutes on one of my SD DirecTivos. By searching this site for "HandleDataChanged" errors, I saw that it appeared to be related to a corruption in MFS. I did a "Clear Program Information and To Do List", and it appears to have worked for the moment. I'm now at about 10 hours without a reboot. I would suggest you do the same, and if that doesn't work try a "Clear and Delete Everything".

Imagr8m8
02-22-2008, 12:42 PM
Thanks for the suggestion. Could you let me know how it works out in a few days...if its a true fix for you? I'm not in a terrible rush to remedy this and end up loosing my recordings if I don't need to, because this is the content I want to get over to the Server (the Server was down for 4 weeks before the Tivo problem with another nightmare). I'm now looking into moving the content from a DTivo drive connected directly to the server....then I wouldn't mind clearing everything.

Luckily, I can try things on one of the drives and still have a way to restore it all from the other AND keep my box plugging away at "necessary" recordings with the original drive while I tinker with it all. So....I have to reiterate to any "freshman" following this thread to heed long-standing advice here...save your original drive untouched AND copy a suspected bad drive to a another drive before tinkering...the extra $50-80 it might cost is WELL worth it.

I do have a thought. I was playing around with transfering content BACK to the Dtvio with Nanvue and many of those programs weren't quite right...stopping halfway through, playing for 5 min when the timeline said 30...stuff like that. Its probably around the time the reboots started to happen...though I was tinkering with other utilities and settings on the DTivo trying to resolve the problems. If I find a way to delete just those programs...might it get rid of problems THEY might be causing...or does their damage still linger in the file system somehow?

whitepelican
02-23-2008, 01:01 AM
Yes, just getting rid of the corrupted shows could solve the problem.

For the record, my Tivo was in a reboot loop for several days with those errors. I did the ""Clear Program Information and To Do List" (which does NOT delete your recordings, by the way) and then I deleted about a half dozen or so of the most recent recordings, which I figured could've been causing the problem. I'm now at about 32 hours without a reboot, and I think it's safe to say the issue is resolved.

Imagr8m8
02-26-2008, 11:39 AM
I popped the HDD with the problems back into the Tivo, deleted a bunch of stuff that I transferred up with Nanvue. But the DTivo crashed about an hour later. I then tried "Clear Program Information and To Do List". I let it go for almost 3 hours with the warning message ("this might take about an hour") on the screen and the red LED flashing...finally I had to pull the power, reinstall the Original drive to make the box functional again for the family. I is a 500GB drive, so I expected it might take a while. I could occasionally hear the drive chugging away, but I never got any sort of message to restart or that it was finished. I'll pop the drive back in today when the box isn't needed for a few hours and see what happened.

But I have a quick question. Since I have the actual recordings mirrored on another drive from the box...is it possible to move the unencrypted recordings to a WinPC if directly connected to the PC...in some way that I can manipulate the individual recordings (ie: convert individual recordings to mpg)? That way I can comfortably just clear everything on the installed Tivo drive and not worry about moving the recordings back, possibly causing the problem again.

Imagr8m8
03-03-2008, 11:49 AM
A quick report back. It took 3 times through "Clear Program Information and To Do List" without ever getting any clear indication that it was finished. But, my DTivo seems to be working correctly again. Perhaps this function does take MANY, many hours for the 500GB drive...though it seemed like the process kept getting hung up. In any case, after letting it "process" over night a few times, then pulling the power and powering back up...the problem seems to be fixed. Thanks for your help. Forums and all their helpful users ROCK!