[maemmoth]

• 0

Hej,
Jag undrar om det är någon som har sett följande fel:

Vid uppspelning av vissa inspelade program visas längden av programmet helt galet. Igår tittade frun på ett Vänner-avsnitt som tydligen skulle vara 10 timmar långt.

Jag kör MythBuntu 9.10 i mitt system. Har inte sett dessa fel tidigare.


Magnus

Redigerat av maemmoth, 16 mars 2010 - 12:20.

[par-joha]

• 0

Hej,
Jag undrar om det är någon som har sett följande fel:

Vid uppspelning av vissa inspelade program visas längden av programmet helt galet. Igår tittade frun på ett Vänner-avsnitt som tydligen skulle vara 10 timmar långt.

Jag kör MythBuntu 9.10 i mitt system. Har inte sett dessa fel tidigare.


Magnus

Har du nyligen uppgraderat eller gjort någon annan förändring?

Mvh, Pär

[maemmoth]

• 0

Har du nyligen uppgraderat eller gjort någon annan förändring?

Mvh, Pär

Jag har uppgraderade typ i januari. Körde innan uppgraderingen OpenSuse 10.3 med MythTv 0.21.
Installerade mythbuntu 9.04 på en ny hårddisk och tog över databasen från den gamla disken.
Uppgraderade därefter till 9.10.

Jag hade lite strul med uppgraderingen. Det löste sig till slut i alla fall.
Är ju tänkbart att det kan finnas något fel i paketen.


Magnus

[frollic]

• 0

Är ju tänkbart att det kan finnas något fel i paketen.

Behöver bara ha blivit något vajjsing med klockan vid fel ögonblick, så får du resultatet du beskrev ovan ....

[par-joha]

• 0

Behöver bara ha blivit något vajjsing med klockan vid fel ögonblick, så får du resultatet du beskrev ovan ....

Min tanke också. Kolla om det är så att de inspelningarna som har fel tidsangivelser är de som gjordes innan uppgraderingen.

/ Pär

[maemmoth]

• 0

Jag har nog med stor sannolikhet hittat felet:
Gjorde en körning med Mythtv log grabber och hittade en del intressant.

==> /var/log/mythtv/mythbackend.log <==
Table './mythconverg/recordedseek' is marked as crashed and last (automatic?) repair failed

2010-03-17 20:13:42.604 DB Error (delta position map insert):
Query was:
INSERT INTO recordedseek (chanid, starttime, mark, type, offset) VALUES ( ? , ? , ? , ? , ? );
Bindings were:
:CHANID=2, :MARK=14465, :OFFSET=180315894, :STARTTIME=2010-03-17T20:00:00,
:TYPE=9
No error type from QSqlError? Strange...
2010-03-17 20:13:42.834 Error preparing query: INSERT INTO recordedseek (chanid, starttime, mark, type, offset) VALUES ( :CHANID , :STARTTIME , :MARK , :TYPE , :OFFSET );
2010-03-17 20:13:43.024 Driver error was [2/144]:
QMYSQL3: Unable to prepare statement
Database error was:
Table './mythconverg/recordedseek' is marked as crashed and last (automatic?) repair failed




Öppnade PhpMyAdmin för databasen och tabellen angiven ovan och hittar samma felmeddelande.

Undrar om migreringen har gått rätt till??? :-)
Har aldrig reparerat en tabell i en databas förut, men någon gång måste ju vara den första.
Någon som har gjort detta?

Hade för övrigt en snubbe från MySql på besök på jobbet för 2 veckor sedan. Synd att man inte hittade felet tidigare :-)

En snabb sökninig och jag hittade på en gång någon som haft samma fel som mig:
http://ubuntuforums....p/t-365155.html


Följde instruktionen och alla tabeller visade status ok efter reparering förutom följande:

mythconverg.recordedseek repair warning Number of rows changed from 5119881 to 665046
mythconverg.weatherdatalayout repair note The storage engine for the table doesn't support r...
mythconverg.weatherscreens repair note The storage engine for the table doesn't support r...
mythconverg.weathersourcesettings repair note The storage engine for the table doesn't support r...

Verkar som att jag tappade en del rader i recordedseek efter repareringen.
För de andra tabellerna så beror statusen på att de kör InnoDb istället för MyISAM.

Redigerat av maemmoth, 17 mars 2010 - 20:41.

[maemmoth]

• 0

Nu är tabellen reparerad, men det var inte det som var felet.
Jag får titta i databasen ikväll och se hur informationen ser ut. Undrar om det står lika galet i databasen eller om det är en feltolkning av frontend eller backend.

Någon som råkar veta vilken tabell som jag ska kolla i?
Annars så hittar jag den säkert efter lite letande.

Magnus

[par-joha]

• 0

Nu är tabellen reparerad, men det var inte det som var felet.
Jag får titta i databasen ikväll och se hur informationen ser ut. Undrar om det står lika galet i databasen eller om det är en feltolkning av frontend eller backend.

Någon som råkar veta vilken tabell som jag ska kolla i?
Annars så hittar jag den säkert efter lite letande.

Magnus

Spontant skulle jag säga 'recorded'-tabellen.

http://www.mythtv.or.../Recorded_table

/ Pär

[maemmoth]

• 0

Spontant skulle jag säga 'recorded'-tabellen.

http://www.mythtv.or.../Recorded_table

/ Pär

Recorded var nog helt rätt.
Problemet är bara att allt verkar schysst där.

Ett exempel nedan:
5 2009-09-15 00:02:00 2009-09-15 00:58:00 CSI Del 4 säsong 9 Nick och Riley utreder ett dödsfall och det visar ... series mythtv 0 0 0 1 1 Default 202 18553 EP1855349 2009-09-15 01:39:16 1092477092 0 0 0000-00-00 0 0 0 0 1 0 5_20090915000200.mpg 2009-09-15 00:00:00 2009-09-15 00:55:00 Default Standard 1 0 0 Default

När jag spelar upp avsnittet och trycker på 'i' så står det att längden är 8 min och 50 s. Det går att se på hela avsnittet men positionsvisaren blir ju lite fel när man passerar 8:50.

Jag har också noterat att det bara är inspelningar äldre än 17 mars 2010 som visar fel.
Om ni tittar i mitt inlägg ovan så var det då jag hittade felet i recordedseek.
Det verkar som att alla inspelningar gjorda efter reparationen visas rätt.

http://www.mythtv.or...ordedseek_table

Frågan är bara vad som kan göras för att rätta till mina fel?
Undrar vad som händer om jag gör en 'Empty' på tabellen?
Verkar som att en hel del rader ändå försvann vid reparationen. Kanske mythtv återskapar datat??