Separate names with a comma.
Discussion in 'DirecTV TiVo Powered PVRs & Receivers' started by incog-neato, Feb 5, 2008.
I got me some 'f' last night! So far so good.
After rebooting for the last several weeks at the exact same time and the exact same days, I am pleased to say:
with 6.3f on my box, it did NOT reboot last night while watching American Idol. Since I installed f, it has not rebooted once.
From TivoWebPlus 2.0 Uptime: 6d 11h 38m 04s
Also, there were audio issues on the HD channels (primarily OTA), where audio would stutter. That is no longer happening either. It did stutter once last night, but if you see my location, we under a tornado warning until 11pm, so it was raining cats and dogs..
However, if those people are right that most of these issues are caused by a bad sector, maybe I will see these problems again if another update comes down and I go back to using the other partition. Until then, I am HAPPY!
You need to put your location in your profile if you want us to know it.
Ummm. Its there... It was just... invisible before. Yeah, thats it. It was invisible before.
I've been f'd and loving it!
So far I've been up
Uptime: 10d 18h 31m 51s
Still an occasional audio glitch, but nowhere near as bad as before. Still extremely happy.
still no love here but if no one has an issue with it i'll keep the line plugged in....i hate my todo list jumping around all the time and am hoping for a fix
I did encounter a strange occurrence with 6.3f on Monday...
My local CBS station OTA wasn't coming in. No signal. I went to check signal strength in Settings. It showed zero. I then checked the other OTA (ABC) that I watch. It also showed zero. I thought that was odd, so I exited changed the channel to the OTA ABC station. No problem, picture came up, looked sharp, perfect. Went back into Settings and checked signal strength again for the ABC channel... Zero. I checked the other OTA channel signals, NADA.
I thought to myself, that can't be right since I can watch some of the channels that show no signal strength. So I restarted the box. After the box restarted, I could then see signal strength for the OTA channels...
So my uptime has been reset, but by me, kind of...
I had a similar issue the other night with 6.3f. Although it appeared that American Idol recorded from my local OTA Fox station, when I tried to watch it, I received a message indicating that the show was not recorded because the recorder could not detect a signal on my local FOX channel. There was nothing in the recording history that indicated a problem. In looking at the information on the American Idol recording, it showed that it recorded 2 hours and the OTA channel was correct. But, it will not play back the recording ... I get the message indicating that the recorder did not detect a signal and it will not allow me to skip past the message. American Idol recorded fine on a 2nd HR10-250 with 6.3f that I own that uses the same roof antenna and set-up. My signal strength for OTA channels is always above 90% (I'm very close to the towers). So, I wonder if this was the same issue that willgetin had where you can watch the OTA channel but the signal strength indicates zero for some reason and the recorder assumes it can not record the program since the signal strength is zero. I have a feeling we are going to hear more issues related to this as more people receive 6.3f. Hopefully this is an isolated case.
I Zippered my 2 HR10-250's about a year or so ago. Both are running 6.3d. I TWP shows only the 6.3d version of the software on both boxes...I never got the D/L for 6.3e. We've been seeing the same reboot issues as many others, and I'm convinced that it's related to CBS, but that seems to have been mentioned here as well.
So, I'm hearing some good things about 6.3f, but I'm concerned that I haven't seen the images come down yet. Is there anything that I need to do on the zippered units to get them to D/L the new slices? I seem to remember that I should expect the units to D/L the slices, but since I have FakeCall running (to allow Caller ID w/o updates), that the new slices would never install. Is this correct, or is there some magic dance-step I need to go through to get 6.3f to D/L.
Thanks in advance,
Here are the commands to get and load the slices for 6.3f on the HR10-250:
Some relevant discussion here, but if you are looking to just force the update, you can do so using normal installSw.tcl methods discussed in the underground and other places.
Just got 6.3f on my SD-Tivo and HD-Tivo in the past week.
I'm trying the method in tivoupgrade's post, as I don't seem to be getting the slices...but I get this error when running sh and the getslice-
You currently have 58 MB of available space on your var partition
You must have at least 86 MB available to unpack slices
Try deleting or moving some files, then run this script again.
I'm sure there's something obvious I'm missing. Can anyone help?
Yeah. You need to delete some stuff in /var to make more room for the slices to fit in there. You need to get rid of at least 28 MB worth of stuff. Either delete it or move it to root (/). Do ls -lR /var > /var/foo. That'll create a text file in /var named foo that lists everything you've got in /var. Attach the "foo" output file here, and maybe we can tell what you can safely get rid of.
Yeah, I think the issue is that I just don't know what to delete. Here's the file. Thanks for your help!
HDTivo-bash# joe foo
IW foo (Modified) Row 2 Col 1 0:31 Ctrl-K H for help
drwxr-xr-x 4 root root 1024 Sep 27 22:52 TWP
drwxr-xr-x 3 root root 1024 Jan 2 1970 cache
-rw-r--r-- 1 root root 450 Feb 17 09:22 cronlog-main
drwxr-xr-x 2 root root 1024 Jan 2 1970 dev
drwxr-xr-x 2 root root 1024 Jul 19 2007 etc
-rw-r--r-- 1 root root 0 Feb 24 00:30 foo
drwxr-xr-x 3 root root 1024 Jul 19 2007 hack
drwxr-xr-x 2 root root 1024 Feb 24 00:28 log
drwxr-xr-x 2 1048576 851968 12288 Jan 2 1970 lost+found
-rw-r--r-- 1 root root 75 Feb 23 22:13 mtab
drwxr-xr-x 2 root root 1024 Feb 22 23:56 packages
drwxr-xr-x 2 root root 1024 Aug 3 2007 persist
drwxr-xr-x 2 root root 1024 Feb 22 01:57 run
drwxr-xr-x 2 root root 1024 Jul 19 2007 spool
drwxr-xr-x 3 root root 1024 Jul 19 2007 state
-rw-r--r-- 1 root root 0 Feb 23 09:54 timestamp
drwxr-xr-x 16 root root 3072 Feb 24 00:30 tmp
drwxr-xr-x 2 root root 1024 Jan 2 1970 utils
-rw-r--r-- 1 root root 2 Jul 19 2007 vardelete_flag
-rw------- 1 root root 5940 Sep 27 22:52 DEADJOE
drwxr-xr-x 2 root root 1024 Jul 19 2007 backups
drwxr-xr-x 2 root root 1024 Dec 11 16:52 config
-rwxr-xr-x 1 root root 7359 Sep 27 22:34 hackman.cfg
-rwxr-xr-x 1 root root 118060 Sep 27 22:34 hackman.itcl
-rwxr-xr-x 1 root root 23098 Sep 27 22:34 hackman_create_cfg.tcl
-rwxr-xr-x 1 root root 30265 Sep 27 22:34 hackman_util.tcl
-rwxr-xr-x 1 root root 6379 Sep 27 22:34 varbackup
-rwxr-xr-x 1 root root 22042 Sep 27 22:34 xPlusz.itcl
-rw-r--r-- 1 root root 1227 Dec 12 19:04 dyncfg.cfg
-rw-r--r-- 1 root root 12000 Sep 27 23:14 hackman.cfg
-rw-r--r-- 1 root root 6420 Sep 27 23:03 module_cache.cfg
-rw-r--r-- 1 root root 398 Jan 11 2007 recoptions.cfg
-rwxr-xr-x 1 root root 1856 Sep 27 23:16 tivoweb.cfg
drwxr-xr-x 3 root root 1024 Jan 2 1970 tivo
drwxr-xr-x 2 root root 9216 Feb 24 00:30 guide
Might want to move all of that TiVoWebPlus stuff out of /var and into a directory in the root partition; that will make a good amount of room.
The added bonus of not keeping apps installed in /var is that they may not vanish mysteriously if /var is to ever be rebuilt due to corruption.
It's /var. You can safely get rid of all of it. The only way there is something in /var which is not expendable is in the event that it has been manually put there. Speaking of, what's a good way to trigger a /var rebuild? I needed to do it once, and just did dd if=/dev/zero of=/var/filename, waited until all the space in /var was used up, and rebooted. I'm sure there's a less crude way to trigger a /var rebuild, no?
I think an "mfsassert -please" will do it. But I wouldn't recommend it even if it did.
I know you can "safely" get rid of it, I was just thinking of possible hacks that could have been stored there. The tivo will rebuild var by using mke2fs if it thinks it's corrupted. Take a look at the StageB_PostKickstart/CleanupVar.sh script.
mfsassert -please is the same as a Kickstart 57 which IIRC, triggers a GSOD. There are examples in some StageA and StageD scripts, checkforpanic.sh and checkmfsassert.sh.
That's only part of it. I meant to use ftp to get it from the tivo and upload as an attachment to your post. You can just delete all of var, but you've obviously got some hacks in there.
6.3f loaded overnight. So far remote seems to have better response.