mysql program table crash - unknown error (1 Viewer)

[HDnewt]

MediaPortal Version: 1.2.1 client
MediaPortal Skin: default
Windows Version: Windows 7 SP1
CPU Type: AMD Phenom X4 910e
HDD: Samsung 500GB
Memory: 4GB DDR3
Motherboard: Gigabyte GA-870A-USB3
Video Card: Zotac GeForce GTX 260² 216 Core
Video Card Driver: newest
Sound Card: onboard
Sound Card Driver: Installation-CD
MPEG2 Video Codec: PowerDVD 11 Ultra
MPEG2 Audio Codec: MPC
h.264 Video Codec: PowerDVD 11 Ultra
Cooling: ThermalRight
Power Supply: Seasonic
Remote: Microsoft MCE Remote
TV: Sony CRT, Samsung SyncMaster 2493HM
TV - HTPC Connection: S-Video, DVI

TV-Server: Windows 7 SP1, Intel Atom N270, 2GB DDR2, 1,5TB Western Digital, MediaPortal 1.2.1
Satelite/CableTV Provider: Astra 19.2°E, Hotbird 13°E
1. TV Card: DE FloppyDTV S2
1. TV Card Type: DVB-S
1. TV Card Driver: 5.7N
2. TV Card: DE FloppyDTV S2
2. TV Card Type: DVB-S
2. TV Card Driver: 5.7N

Hello,

tv didn't start on my client yesterday and I got an unknown error message on my tv client. After some research I found the reason in the mysql database, the program table was crashed. The tv server was working without problems for about 1 month.
I don't know why it happened, it just crashed. I added the log files of the tv server, the tv client installed on the server pc and a mysql database backup.

Greeting HDnewt

 

[mm1352000]

Hi HDnewt

Did you also find out how to do the mysqlcheck --autorepair? DB corruption issues are generally caused when the DB is not shut down cleanly. That might happen with power outages, manual "hard" reboots, BSODs, HDD disconnections etc.

mm

 

[HDnewt]

AW: mysql program table crash - unknown error

Hi mm,

yes I did the autorepair after doing the backup and it is working fine again. I did not turn of the server for about 3 weeks, no sleep mode, no hibernation, it was just running day and night. It was still running when I checked mysql, so it just stopped working spontaneously after weeks without any problems. I thought the logs could be interesting, because it happened without any obvious reason.

HDnewt

 

[mm1352000]

Hi again HDnewt

Just to follow up on this thread...
It is my guess that the EPG grabber was partly to blame. I'm not 100% certain that the logs contain the detail for when the problem actually started, but if they do then the problems started immediately after the EPG grabber updated the database with new program information. Unfortunately the DB dump doesn't contain the tuples from the affected table (Program). I will say that whenever this problem is reported it *always* (literally without fail) affects that table, which makes me suspicious of the EPG grabber...

mm

 

[syntec]

I had a hard crash today with the same result "Unknown error" when trying to startup TV (StartingTV-Service also takes very long). Isn´t it possible to fix the programme table automaticaly with the TABLE REPAIR command? It's quite obvious that there's something wrong with EPG/programme when the empty EPG is showing up...

 

[HDnewt]

Hello,

I have to pick up my old thread. I experienced this database crash about 3 times in the last months from january on. Today the program table in the mysql database mptvdb is marked as crashed again and I have repair it. I don't know if it is a configuration problem or a bug. I am using MediaPortal version 1.2.3 actually. The hardware is still the same. I added the logs and the database of today. Maybe it happens because I enabled CRC check?
My last scan for channels was in july, but there is still a tswriter log, I also get an error and an epg log. I hope the db dump contains the program table, i just did a complete mptvdb backup. Any suggestion would be great.

HDnewt

 

[mm1352000]

Hi HDnewt

I don't know if it is a configuration problem or a bug.

This issue only affects MySQL. It is not so much a bug as a design choice.
In technical speak the issue is this: the MySQL table engine that we use (MyISAM) does not support transactions.

There is a trade-off that we're making between database access speed and absolute reliability.
When two processes try to write to a table at the same time this has to be carefully managed.
You can force one process to wait for the other to be done (slower) or assume that this won't happen in practice (faster).
Normally since there is only one TV Server there should only be one process that writes to the database. Hence we picked the faster option.
Some people have no problems.
Other people such as yourself seem to experience this on a semi-regular basis.
Configuration will certainly have an impact. For example, whether you use the EPG grabber or not likely makes a big difference.
If you want better reliability, use an SQL Server database. It supports transactions.

I am using MediaPortal version 1.2.3 actually. The hardware is still the same. I added the logs and the database of today. Maybe it happens because I enabled CRC check?

It isn't the CRC check.

My last scan for channels was in july, but there is still a tswriter log,

The TsWriter is responsible for timeshifting, recording and EPG grabbing as well as scanning. Presumably you've done some of that since July.

I also get an error and an epg log.

Normal.

I hope the db dump contains the program table, i just did a complete mptvdb backup. Any suggestion would be great.

The program table seems to be the problem 90% of the time.
There is nothing that we can particularly do about this without changing the way we use MySQL... and that may happen, but it won't happen overnight. Using a more recent MySQL release may help as well.
As mentioned above, use SQL Server if you want the problem to go away now.

mm

 

[SciDoctor]

This may also be affecting MS SQL (2005 and 2008 tested) as indicated in this thread.

https://forum.team-mediaportal.com/...ervice-unhandled-app-domain-exception.108302/

This quote above being the important part

"There is a trade-off that we're making between database access speed and absolute reliability.
When two processes try to write to a table at the same time this has to be carefully managed.
You can force one process to wait for the other to be done (slower) or assume that this won't happen in practice (faster).
Normally since there is only one TV Server there should only be one process that writes to the database. Hence we picked the faster option"

Is it possible to have a test TsWriter with the slower "wait for process to be done" active isntead of the faster one which is causing the concurrent access conflicts.

 

[HDnewt]

Thank you for the new input and for the explanation. I will try another MySQL version. I have been using MS SQL before and I did not have this problem that time. But this was about 3 years ago and a lot of things changed in my setup.

hdnewt