Problems downloading EPG data via POTS

[Countryman]

Anyone else having problems today ? Keep getting either 'call not answered' or 'Failed. Call interrupted'.

[steveroe]

My tivo, connected by network, hasn't been able to download since Thursday ("UnknownError") and I see from the server statistics http://www.altepg.com/serverStatistics.html that there are an unusually high number of connections from 16th and 17th - is there a problem with the server at present causing failed connections and multiple retries?

Unrelated, or not, it has also briefly gone to the green screen of death twice this morning... maybe on its way out

Edit: Looks like each time it tries to do a daily call it then reboots after downloading the slices...

Server logs from last attempt:

ird_id Sat Sep 17 08:01:09 2016 Sat Sep 17 08:02:11 2016 ID=5320538E
TCD411 195.226.54.xxx Sat Sep 17 08:02:12 2016 _
HServer 195.226.54.xxx Sat Sep 17 08:02:13 2016 _
mlog 195.226.54.xxx Sat Sep 17 08:02:36 2016 _
tcd_driveid Sat Sep 17 08:01:09 2016 Sat Sep 17 08:02:12 2016 HDA=PV7974ZH09GB8V HDB=Unknown
tclient_download Sat Sep 17 08:01:09 2016 Sat Sep 17 08:02:17 2016 FILE=/tivo-static/ukheadends/message-20000043.slice STATUS=New
tclient_download Sat Sep 17 08:01:09 2016 Sat Sep 17 08:02:17 2016 FILE=/tivo-static/tmsid-listings/UK01006_17059-17075.slice.gz STATUS=New
tclient_download Sat Sep 17 08:01:09 2016 Sat Sep 17 08:02:28 2016 FILE=/tivo-static/tmsid-listings/UK01005_17058-17074.slice.gz STATUS=New
tclient_download Sat Sep 17 08:01:09 2016 Sat Sep 17 08:02:36 2016 FILE=/tivo-static/tmsid-listings/UK01005_17059-17075.slice.gz STATUS=New
tclient_download Sat Sep 17 08:01:09 2016 Sat Sep 17 08:02:36 2016 FILE=/tivo-static/tmsid-listings/UK01006_17058-17074.slice.gz STATUS=New

Maybe an issue with one of the slice files, each time before reboot I get the following as the last entry in tclient

09/17:07:02:39: /tvbin/TClient: dbload UK01005_17058-17074.slice...

[cerihp]

Similar problem here; since yesterday morning my TiVo has rebooted over a dozen times, each time bailing out part way through loading data. The slice in question for me is UK01013_17058-17074.slice, which I guess is the same day's data for a different line up (I have Sky HD & Sky radio)

The reboots are accompanied by these messages in the tverr log:

Sep 17 02:45:31 (none) DbObject[372]: Missing required attribute 0x70010
Sep 17 02:45:31 (none) DbObject[372]: 1b58a20 1b526cc 1b893d4 1b891ec 1cadd84 1cadb6c 1cad8a0 1caf9f4 1caf664 1cad8b0 1cad700 1c506cc 1c4d810 1c77e7c 1c61a10 1c597b8
Sep 17 02:45:31 (none) DbObject[372]: Missing required attribute 0x70010
Sep 17 02:45:31 (none) DbObject[372]: 1b58a20 1b58878 1b57fd8 1b53db4 1b5291c 1b598d4 1b597ac 19fabd0 19fae44 1b56d74 1b5260c 1b893d4 1b891ec 1cadd84 1cadf28 1cadb6c
Sep 17 02:45:32 (none) FsVolume[372]: Assert failed: this->CheckSchema() == 0x00000000 at object.C line 396 in DbObject::DbObject(class DbDatabase *, class DbFile *, struct DbObjectHeader *)
Sep 17 02:45:34 (none) TmkAssertionFailure[372]: this->CheckSchema() == 0x00000000 (DbObject::DbObject(class DbDatabase *, class DbFile *, struct DbObjectHeader *), line 396 (object.C))
Sep 17 02:45:34 (none) tivosh[372]: Tmk Fatal Error: Thread tivosh <372> died due to signal -2
Sep 17 02:45:34 (none) tivosh[372]: Tmk Thread Backtrace: 1a344ec 1a32a44 1a1a604 1b58000 1b53db4 1b5291c 1b598d4 1b597ac 19fabd0 19fae44 1b56d74 1b5260c 1b893d4 1b891ec 1cadd84 1cadf28 1cadb6c 1cad8a0 1caf9f4 1caf664 1cad8b0 1cad700 1c506cc 1c4d810 1c77e7c 1c61a10 1c597b8 1c58300 1c58a7c 1c77e7c 1c61a10 1c597b8 1c58300 1c58a7c 1c5d190 1c5a568 1c77e7c 1c61a10 1c597b8 1c58300 1c58a7c 1c5d190 1c5a568 1c77e7c 1c61a10 1c849c0 1c85ec8 1c4d248 1c28cac 1800134 ipe
Sep 17 02:45:34 (none) tivosh[372]: Tmk Fatal Error: Thread died due to signal -2
Sep 17 02:45:34 (none) tivosh[372]: Invoking rule 834: rebooting system
Sep 17 02:48:19 (none) MfsDaemon[138]: Unable to initialize MFS
Sep 17 02:51:51 (none) FsVolume[140]: Non-daemon Sync() by 140
Sep 17 02:51:52 (none) MFS[140]: volume marked as needing database cleanup
Sep 17 02:51:54 (none) FsVolume[141]: Non-daemon Sync() by 141
Sep 17 03:46:17 (none) DbObject[382]: Missing required attribute 0x70010
Sep 17 03:46:17 (none) DbObject[382]: 1b58a20 1b526cc 1b893d4 1b891ec 1cadd84 1cadb6c 1cad8a0 1caf9f4 1caf664 1cad8b0 1cad700 1c506cc 1c4d810 1c77e7c 1c61a10 1c597b8
Sep 17 03:46:17 (none) DbObject[382]: Missing required attribute 0x70010
Sep 17 03:46:17 (none) DbObject[382]: 1b58a20 1b58878 1b57fd8 1b53db4 1b5291c 1b598d4 1b597ac 19fabd0 19fae44 1b56d74 1b5260c 1b893d4 1b891ec 1cadd84 1cadf28 1cadb6c
Sep 17 03:46:18 (none) FsVolume[382]: Assert failed: this->CheckSchema() == 0x00000000 at object.C line 396 in DbObject::DbObject(class DbDatabase *, class DbFile *, struct DbObjectHeader *)
Sep 17 03:46:20 (none) TmkAssertionFailure[382]: this->CheckSchema() == 0x00000000 (DbObject::DbObject(class DbDatabase *, class DbFile *, struct DbObjectHeader *), line 396 (object.C))
Sep 17 03:46:20 (none) tivosh[382]: Tmk Fatal Error: Thread tivosh <382> died due to signal -2
Sep 17 03:46:20 (none) tivosh[382]: Tmk Thread Backtrace: 1a344ec 1a32a44 1a1a604 1b58000 1b53db4 1b5291c 1b598d4 1b597ac 19fabd0 19fae44 1b56d74 1b5260c 1b893d4 1b891ec 1cadd84 1cadf28 1cadb6c 1cad8a0 1caf9f4 1caf664 1cad8b0 1cad700 1c506cc 1c4d810 1c77e7c 1c61a10 1c597b8 1c58300 1c58a7c 1c77e7c 1c61a10 1c597b8 1c58300 1c58a7c 1c5d190 1c5a568 1c77e7c 1c61a10 1c597b8 1c58300 1c58a7c 1c5d190 1c5a568 1c77e7c 1c61a10 1c849c0 1c85ec8 1c4d248 1c28cac 1800134 ipe
Sep 17 03:46:20 (none) tivosh[382]: Tmk Fatal Error: Thread died due to signal -2
Sep 17 03:46:20 (none) tivosh[382]: Invoking rule 834: rebooting system
Sep 17 03:49:04 (none) MfsDaemon[138]: Unable to initialize MFS
Sep 17 03:52:34 (none) FsVolume[140]: Non-daemon Sync() by 140
Sep 17 03:52:35 (none) MFS[140]: volume marked as needing database cleanup
Sep 17 03:52:37 (none) FsVolume[141]: Non-daemon Sync() by 141
Sep 17 04:48:59 (none) DbObject[374]: Missing required attribute 0x70010
...

The numbers appear to be consistent, so hopefully may identify the problem.

mfscheck passes the database as clean every time.

I'm about to unplug the network cable as the machine appears to be stable so long as it doesn't try to update the database, but restarts every few hours otherwise.

Anyone know what attribute 0x70010 is supposed to be?

[steveroe]

Phew - this is, perversely, good news as it does indicate the problem is not our machines but the slice files in question.

Can someone take a look at rebuilding them on the server, they seem to be corrupt!

Also disconnecting the network here...

[bigwold1]

And I thought it was just me. Same problem here. TiVo network connected x 2, last successful calls/loads Thursday morning. Each attempt fails partway through loading data and then GSOD. Test call works fine, it's just the loading data that fails. TClient last entries from calls just now same as steveroe:
TiVo1
09/17:07:48:37: /tvbin/TClient: dbload UK01005_17058-17074.slice...
TiVo2
09/17:07:48:58: /tvbin/TClient: dbload UK01005_17058-17074.slice...

[steveroe]

I've sent some PMs to people who may be able to help.

[Mike Sugar]

Same problem with me yesterday - attempted (5) updates yesterday - all aborted and went to GSOD.

Before finding this post this morning, have just stripped down Tivo and fitted spare HDD. Just initiated update, and in front of my eyes now, has aborted just the same and gone to GSOD.

Thank goodness it is a share problem and not my Tivo dying.

Will now re-fit original HDD and keep fingers crossed for "repair."

Mike.

[Teepee]

Same problem with me yesterday - attempted (5) updates yesterday - all aborted and went to GSOD.

Before finding this post this morning, have just stripped down Tivo and fitted spare HDD. Just initiated update, and in front of my eyes now, has aborted just the same and gone to GSOD.

Thank goodness it is a share problem and not my Tivo dying.

Will now re-fit original HDD and keep fingers crossed for "repair."

Mike.

Hi Mike,

I have three Tivos and they all exhibit the same symptoms. They start downloading, then restart before completion and go to GSOD for about fifteen minutes before recovering, albeit without any new guide data. One of them lost remote control access for about an hour before recovering. My advice would be to leave the machine on (as suggested on GSOD) and let it recover by itself.

[Mike Sugar]

Hi Teepee,

Yes, understood.

As a further action. I was going to replace PSU.

Have now re-fitted original HDD back into No. 1 working Tivo, with network cable
disconnected, and hopefully wait for "repair."

Mike.

[steveroe]

Yes, as noted by cerihp above, disconnecting from the network/phone line stops the download and the rebooting

[positor1]

Oh no, I have spent all yesterday and till now today; re burning drives and swapping TiVo parts around because my TiVo went gsod (green screen of death) Friday morning.
All attempts at completing guided setup data have resulted in GSOD
I have now taken the drive to another TiVo that is still working to complete GS (guided setup)
I wonder if that will be successful?

[positor1]

Anyone else having problems today ? Keep getting either 'call not answered' or 'Failed. Call interrupted'.

what on earth is POTS?

[steveroe]

Oh no, I have spent all yesterday and till now today; re burning drives and swapping TiVo parts around because my TiVo went gsod (green screen of death) Friday morning.
All attempts at completing guided setup data have resulted in GSOD
I have now taken the drive to another TiVo that is still working to complete GS (guided setup)
I wonder if that will be successful?

Unlikely, the problem seems to be caused by some of the guide data that is being downloaded.

[steveroe]

Anyone else having problems today ? Keep getting either 'call not answered' or 'Failed. Call interrupted'.

what on earth is POTS?

Plain Old Telephone Service - dialup, although I think the issue this thread was originally created for may actually be the guide data issue, the timings are the same.

[Furbag]

Yep same problem with mums TiVo on Dial Up, gets to about 50% and then GSOD's with severe internal error

Was worried till I noticed a huge spike in the dail call logs stats http://www.altepg.com/serverStatistics.html and thought it cant be just mums falling over to rebuild itself after a 10min GSOD moment.

For now I'll sit tight and let the powers to be see if they can find the problem.