AltEPG

Just one observation after upgrading one of my TiVo's using the AltEPG ISO image:

When I go into Pick Programmes To Record / Search or Wishlist, select the genre (or all), there is what appears to be a completely blank screen. At first I thought the TiVo had hung, or that maybe the database build was still running in the background somewhere, so I left it overnight.

This morning the same thing happened, but I realised that if you just press Select, it then takes you on to the screen where you enter the title or keyword.

Couldn't find this on the forum as a known issue anywhere - any ideas?

Hi

You've used a broken or old image which is missing the Ouija board background movie. See this post for why it happens.

I'm sure this was fixed well before 1.0c though?

Hmmm, strange, we did fix the image that we are using on the ISO CD.

This thread should also fix an image does have the problem without having to restore etc:

viewtopic.php?f=16&t=471

As you say this issue was fixed some time ago in the ISO CD.
However I have had one other report recently of a similar problem with the current ISO, so will keep an eye on it.
@russmacdonald can you confirm which version of the image you used and also whether the fix suggested by Dave (viewtopic.php?f=16&t=471) sorts it out?

I also had that problem, but can't remember which version of the ISO was used (not much help I know ). But I can confirm that the fix in the linked thread has fixed it

Here is a screengrab from the background movie in question, for ease of future reference.

To update my earlier post, my install.log shows:

Code: Select all

2011-09-17:23:47:40: INFO: prerequisites complete
2011-09-17:23:47:40: INFO: Starting Install
2011-09-17:23:47:40: INFO: Installing packages from /mnt/tivoRoot/var/packages
2011-09-17:23:47:40: INFO: Installing altepg1.0c_install
2011-09-17:23:47:43: INFO: Install Complete (error=0)

So it looks like I am on 1.0C and did have the "blank ouija" problem. Using the fix linked cured it.

Thanks everyone for help on this. I applied the patch successfully and it's now working perfectly.

As I posted here http://www.tivoland.com/forum/viewtopic.php?f=16&t=471&p=10374#p10346, the current ISO image doesn't appear to contain the patch.

I'll second that.
The problem is present in version 1.0c_1

Nick

Dave,
Is it work adding a thread for problem reports in current versions so we can all look in the same place?
You could add a patch and known issues stickys to avoid dupicated reports and maybe a format guide for bug reporting:
E.g
Release Version: 1.0c
HW Summary: 1TB Sata, Cachecard
Problem with: Installer, TWeb, guide etc...
Steps to reproduce:

I had this problem, and my system came from a Tivoland image over a year ago when they upgraded the disk. I never knew what the cause was, until I saw this thread.

Now, in my haste of trying to fix it, I've messed up my TiVo.

I first attempted to mfs_import the file at the given MFSID, but it reported that was an invalid number.
I then (clearly wrongly) imported the PickByNameNonSky0.mpv file at the MFSID that it appeared to reside in my system (starting at 167976). Then visited the screen where it should be, and TiVo rebooted and came up to the GSOD (mfs_checking, right?)

Now, over 24 hours later, I can telnet back into the system but it's not completing its boot. The MFS /SwSystem directory seems to be completely missing, as shown by mls.

Are there any easy routes to fixing it?

swiftnick wrote:I'll second that.
The problem is present in version 1.0c_1

Nick

Dave,
Is it work adding a thread for problem reports in current versions so we can all look in the same place?
You could add a patch and known issues stickys to avoid dupicated reports and maybe a format guide for bug reporting:
E.g
Release Version: 1.0c
HW Summary: 1TB Sata, Cachecard
Problem with: Installer, TWeb, guide etc...
Steps to reproduce:

Known issues are captured in the release notes for 1.0c : viewtopic.php?f=16&t=1005
That should probably be a sticky, of course. Will make it so for the next release.

jrg wrote:I first attempted to mfs_import the file at the given MFSID, but it reported that was an invalid number.
I then (clearly wrongly) imported the PickByNameNonSky0.mpv file at the MFSID that it appeared to reside in my system (starting at 167976). Then visited the screen where it should be, and TiVo rebooted and came up to the GSOD (mfs_checking, right?)

Now, over 24 hours later, I can telnet back into the system but it's not completing its boot. The MFS /SwSystem directory seems to be completely missing, as shown by mls.

Are there any easy routes to fixing it?

The right instruction for importing that mpv is:

Code: Select all

mfs_import 6398 PickByNameNonSky0.mpv


6398 is the correct location for tivos based on the altepg1.0c image, but may not be right for others.

Did you do:

Code: Select all

mfs_import 167976 PickByNameNonSky0.mpv


millsb wrote:The right instruction for importing that mpv is:

Code: Select all

mfs_import 6398 PickByNameNonSky0.mpv


Well, that would explain the failure... I took the command from the ouija_fix.sh script, which had it as

Code: Select all

        Yes ) mount -o remount,rw /; ./mfs_import 6398 < PickByNameNonSky0.mpv; echo "All Done."; break;;


Code: Select all

mfs_import 167976 PickByNameNonSky0.mpv


I used the mfsid from my system, but had used the 'from stdin' form that ouija_fix.sh used.

Either way, that clearly upset TiVo. On the mfs_check, it logged:

Code: Select all

Jan 23 23:56:08 (none) kernel: mfscheck scan begins
Jan 23 23:57:40 (none) kernel: Object 167976 size mismatch: MFS size = 204, obj size = 2
Jan 23 23:58:49 (none) kernel: Checking reference counts
Jan 23 23:58:49 (none) kernel: There are 1 database objects marked corrupt.
Jan 23 23:58:49 (none) kernel: Destroying file 167976
Jan 23 23:58:49 (none) kernel: Directory 168673 has dangling reference to 167976
 Jan 23 23:58:49 (none) kernel: Directory 1081995 has dangling reference to 167976
Jan 23 23:58:49 (none) kernel: Directory 111 has dangling reference to 167976
Jan 23 23:58:49 (none) kernel: Database object 167978 has dangling reference to 167976
Jan 23 23:58:49 (none) kernel: There are 1 database objects marked corrupt.
Jan 23 23:58:49 (none) kernel: Destroying file 167978
Jan 23 23:58:49 (none) kernel: Directory 131 has dangling reference to 167978
Jan 23 23:58:49 (none) kernel: Directory 1081995 has dangling reference to 167978
Jan 23 23:58:49 (none) kernel: Database object 168003 has dangling reference to 167978
Jan 23 23:58:49 (none) kernel: There are 1 database objects marked corrupt.
Jan 23 23:58:49 (none) kernel: Destroying file 168003
Jan 23 23:58:49 (none) kernel: Directory 1081995 has dangling reference to 168003
Jan 23 23:58:49 (none) kernel: Database object 167997 has dangling reference to 168003
Jan 23 23:58:49 (none) kernel: There are 1 database objects marked corrupt.
Jan 23 23:58:50 (none) kernel: Destroying file 167997
Jan 23 23:58:50 (none) kernel: Directory 643 has dangling reference to 167997
Jan 23 23:58:50 (none) kernel: Directory 643 has dangling reference to 167997
Jan 23 23:58:50 (none) kernel: Directory 1081995 has dangling reference to 167997
Jan 23 23:58:50 (none) kernel: Destroyed a total of 4 files
Jan 23 23:58:50 (none) kernel: FIXING: file 108 refcount (changing from 4 to 3) object reasonable
Jan 23 23:58:50 (none) kernel: FIXING: file 112 refcount (changing from 4 to 3) object reasonable
... [ a lot more FIXING: file refcounts here ]
Jan 23 23:59:12 (none) kernel: Rebulding all directories
Jan 23 23:59:12 (none) kernel: Wrote new, empty root directory (0x00000000)
... [ followed by a lot of Link reports with mfs paths ]


so I can see that after deciding the {167976 PickByNameNonSky0.mpv} entry was corrupt it has removed the references to it (oops)

but I've somehow ended up without /SwSystem, after the GSOD kicked in, as well.

This is looking like it might be beyond simple repair.

jrg wrote:but I've somehow ended up without /SwSystem, after the GSOD kicked in, as well.

This is looking like it might be beyond simple repair.

I think an empty /SwSystem is pretty fatal yeah

You can pull the drives, put into a PC and use the "vplay" tools to get the recordings out of MFS though, if you are planning on reimaging.

Having just made our new Network TiVo live I set the Mrs's to work re-doing all the SP's etc

Anyhow 10mins later I get a shout saying theres no Seach facility i.e it returns a blank screen

So a quick look here and I see its actually there but you just have to press right twice to get to it, so having read all of the above I'm still none the wise as to if theres a fix to this

Is their a patch script that needs to be run similar to the patch for the cache card one