02:00:01 (none) prioritizer[153]: ProcessOneFromIterator got errDbNotFound

Sometimes, the errDbNotFound errors are caused by database corruption that mfsfix (the dreaded GSOD) can correct. To just check for errors (without forcing a GSOD), try running mfscheck at the bash prompt. This is no different to running scandisk or chkdsk on a PC.

 

Probably, but my knowledge is limited as to what mfsfix can do if mfscheck can't find anything.

 

Advertisements

My tivo has just started doing the same. 2.5G tvlog file!!! Did you ever find out why (or find a fix)?

 

I just ran mfscheck on Tivo1, which has been randomly rebooting, and it threw up Segmentation fault, and then rebooted.

I can see that looks bad; can anyone say how bad, or suggest fixes, if any?

[Edit]
It didn't reboot! Something much more interesting happened.

The Tivo froze. I mean everything.

No response to TivoWeb.
No response to telnet.
No response to the remote.
A programme was onscreen, paused where I'd left it.
The recording light was lit.

I pulled the plug, and it's back up, for now.

 

I did this now, just for the hell of it and here's what happened:

Code:

Welcome to the wonderful world of TiVo hacking :)
Filesystem on / set to READONLY - type rw to make READ/WRITE
TiVo: {/var/tmp} % mfscheck
EventSwitcher stopped
mfscheck scan begins
Checking reference counts
All reference counts are OK.
mfscheck scan ends
mfscheck: 0 fatal errors, 0 severe errors, 0 warnings.

You must manually restart the EventSwitcher
TiVo: {/var/tmp} %

That's all very well, but...
1. what's the EventSwitcher
2. how do I re-start it
and
3. will my Tivo work okay without doing so? Hope so as I'm recording "Torchwood" in the early hours

You didn't mention that bit, ian

Edited to add:
Well, now I know the answer. Tivo wouldn't respond to the remote at all and I had to do a hard re-boot; ie pul the plug

So, won't be doing that again in a hurry

 

Carl - "Snap!"

I think the phrase most appropriate to us is
"A little knowledge is a dangerous thing."

 

Yeah. I did read your post. I just forgot I had or I might not have done it

 

That's what happened to me

However, since the reboot, it still does the
prioritizer[152]: ProcessOneFromIterator got errDbNotFound
message between 02:00:00 and 05:00:00. The log has...

Sep 15 04:59:59 (none) prioritizer[152]: ProcessOneFromIterator got errDbNotFound
Sep 15 04:59:59 (none) TmkMediaswitch::Trace[148]: Lost VBI lock
Sep 15 05:00:00 (none) last message repeated 8 times

repeated every second.

Then from 05:00:00 it has...

Sep 15 05:00:00 (none) TmkMediaswitch::Trace[148]: Lost VBI lock
Sep 15 05:00:31 (none) last message repeated 279 times
Sep 15 05:01:32 (none) last message repeated 555 times
Sep 15 05:02:33 (none) last message repeated 554 times
Sep 15 05:03:34 (none) last message repeated 555 times
Sep 15 05:03:50 (none) last message repeated 150 times

which is still going on. Tivo stills seems to be recording OK it's just the the tvlog file gets huge.

The only thing I did which may have triggered this is to change the Best recording mode (for CAB) from 2 to 4 and switch on VBR by lowering the BestVBRrate using the value suggested in blindlemon's resetmode0 script.

 

Well I just ran it for the hell of it. I'm not having any sort of problems with my Tivo at the moment However, I've juat had a look and I too am getting a lot of similar messages the tvlog file.

First:
Sep 15 02:07:50 (none) prioritizer[169]: ProcessOneFromIterator got errDbNotFound
Sep 15 02:07:50 (none) TmkMediaswitch::Trace[165]: Lost VBI lock
Sep 15 02:07:51 (none) last message repeated 8 times
Last:
Sep 15 04:59:41 (none) prioritizer[169]: ProcessOneFromIterator got errDbNotFound
Sep 15 04:59:59 (none) last message repeated 18 times

and that's just since the re-boot around midnight!

 

I've gleaned some info over the years which may help. First of all don't do any of this if you're recording anything on the TiVo which you want. The EventSwitcher runs TiVo's UI, and you can't check&fix the MFS whilst tivo is doing anything, which is why it gets stopped. Rebooting is the only way to start it up again. Also close down tivoweb, endpad, irblast and anything else you have running first.

mfscheck does a check and then runs fsfix to perform fixes if it thinks they are needed. But remember the "kickstart" codes, which you can run by pressing keys on the remote during reboot - if you read the /etc/rc.d startup files you'll see what they do.

eg Kickstart code 5 8 - perform MFS cleanup
actually runs
/tvbin/fsfix -nokill -splash -uncollide -rehash -salvage -reboot

So you can always run fsfix independantly, which saves all the waiting for mfscheck.

You'll get output like

Code:

Writing 401560 bytes to OSD at address 0

			[this was the
		"Installing new software from the TiVo Service. This will take a few minutes"
			splash screen]

fsfix:  mounted MFS volume, starting consistency checks.
I-Nodes:
I-Node table size is 131072 entries for 100000 active nodes max.
FsId high-water mark is 0x20ee2c
		[these passes were about 2-3 mins each]
Pass 1 - scan and analyze
Pass 2 - try to compact inode table by rehashing
Pass 3 - scan and analyze
Pass 4 - clear superfluous collision bits
Pass 5 - scan and analyze
reconstructing zone buddymaps
synchronizing...
volume marked as OK
scanned 63932 files, covering 20315 extents
1048400 application pages in use
28385280 media pages in use
Inode table collision details
10127 hash collisions in node table.
15 hash collisions in longest run.
15 hash collisions in longest busy run.
8396 files aren't in their primary hash locations.
4535 files were successfully rehashed.
24198 hash-collision bits were cleared.
Allocation Details
44356/63846 application inline files, 69.47%
91.7% wasted space (0 bytes) in normal application region
44.77% wasted space (0 bytes) in inlined application region
86 media files
84.76% wasted space (0 bytes) in media region
Fragmentation:
average  extents/file is 0.31
worst    extents/file is 11
expected extents/file (approx) is 3
 Application region:
zone contains 785104 pages: 209680 allocated; 575424 free
inode allocations match allocated page count
buddy-map is internally consistent, 575424 pages marked free
Media region:
zone contains 76193792 pages: 3317760 allocated; 72876032 free
inode allocations match allocated page count
buddy-map is internally consistent, 72876032 pages marked free
zone contains 241598464 pages: 294912 allocated; 241303552 free
inode allocations match allocated page count
buddy-map is internally consistent, 241303552 pages marked free
zone contains 168132608 pages: 2064384 allocated; 166068224 free
inode allocations match allocated page count
buddy-map is internally consistent, 166068224 pages marked free
fsfix: 0 fatal errors, 0 warnings.

fsfix rebooting system

Personally I don't see the harm in, and quite like the idea of, passes 2 and 4. They might help, and if you were to run mfscheck on its own and it didn't want to run fsfix, then they'd never happen.

Do this at your own risk of course . Keep the telnet window open if you want to save the output, because it reboots tivo at the end of the process.

 

You're over-reacting. See my other post for why you need to reboot - and you do not have to pull the plug. Just type "restart" or "reboot" at the bash prompt.

 

Me? Over-react? Never. Unlike a lot of Northern Rock account holders

I just had around 50 days up-time and I wanted to see how long I could keep it going. Doesn't usually get that far