recordings section empty after every restart (1 Viewer)

kkendall

Portal Pro
April 24, 2007
864
16
43
Gouda
Home Country
Netherlands Netherlands
MediaPortal Version: MP 1.2.0
MediaPortal Skin: StreamedMP
Windows Version: Windows 7
CPU Type: Intel Core 2 Duo E6750 775 1333FSB 2.66Ghz 4MB
HDD: Intel Postville SSD 80GB
Memory: 2x Kingston DDR2 ValueRAM 1GB 667 CL5.0
Motherboard: Asus P5K
Video Card: NVIDIA 9600 (passive)
Video Card Driver: latest
Sound Card:
Sound Card AC3: AC3 and DTS: S/PDIF
Sound Card Driver: latest
1. TV Card: FloppyDTV
1. TV Card Type: DVB-C
1. TV Card Driver: latest
2. TV Card:
2. TV Card Type:
2. TV Card Driver:
3. TV Card:
3. TV Card Type:
3. TV Card Driver:
4. TV Card:
4. TV Card Type:
4. TV Card Driver:
MPEG2 Video Codec: PowerDVD 10 (SAF 5.00)
MPEG2 Audio Codec: ffdshow (SAF 5.00)
h.264 Video Codec: PowerDVD 10 (SAF 5.00)
Satelite/CableTV Provider: CAIWAY
HTPC Case: Silverstone LC17b
Cooling: 1x 80 mm fan + 1 x cpu fan
Power Supply: ANTEC
Remote: Microsoft MCE 2005 remote
TV: Panasonic TH-42PZ85
TV - HTPC Connection: DVI-HDMI

Since the installation of MP 1.2 final, the recording section is empty every time I start up MP after a restart of my pc...
I can import all my recordings in the config again. But after every restart, they're gone again.
Anyone got a solution?
Logs attached
 

jameson_uk

Retired Team Member
  • Premium Supporter
  • January 27, 2005
    7,258
    2,528
    Birmingham
    Home Country
    United Kingdom United Kingdom
    could you just check your database
    Open up a command prompt (as admin if Vista / Win7)
    navigate to MySQL Bin folder (is C:\\Program Files\\MySQL\\MySQL Server 5.1\\bin for me) and enter
    Code:
    mysqlcheck --user=root --pass=MediaPortal --auto-repair MPTVDB

    if that does not fix it there are lots of errors in your logs like
    Code:
    2011-09-19 22:10:16.283954 [scheduler thread(10)]: Exception   :System.UnauthorizedAccessException: Toegang tot het pad \\DISKSTATION\Recordings\Nederland 3 HD\Neonletters (AVRO) is geweigerd.

    This would suggest that MP is struggling to access this folder (recordings are being stored on your server rather than locally ?)
     

    kkendall

    Portal Pro
    April 24, 2007
    864
    16
    43
    Gouda
    Home Country
    Netherlands Netherlands
    Thank's man, for your input!
    Your remark about the external disk made me remember that it could be the account that the service was running on...I checked the tv service under administrative tools - services and the update from 1.2rc to 1.2 final set the account back to 'local' instead of the account from my NAS!
    Editing it and setting this back to the correct account solved it.
    Is it an idea or an option for future releases to keep these account settings as they are set by the user, when updating? Is that possible?

    EDIT: Is it possible to give some error message of some kind when this happens? Now the recordings crash, start and stop, tvcards hang, recording section is emptied, etc....but no error message or warning.
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    jameson_uk: I wonder could we do an automatic mysqlcheck and auto-repair on TV Server startup? This would slow down resume from sleep/hibernate a little, but it would allow us to avoid the steady trickle of issues we get with corrupted database tables. Of course this feels like patching symptoms - can we track the corruption back to its source? It always seems to be the program table. Maybe that is just because the program table is heavily used, but it could also be because the EPG grabber or a particular plugin causes trouble...

    mm
     

    arion_p

    Retired Team Member
  • Premium Supporter
  • February 7, 2007
    3,373
    1,626
    Athens
    Home Country
    Greece Greece
    There is no way an application can cause table corruption in MySQL (or MSSQL). The only ways to get a table corrupt are:

    • power outage / hard reset
    • OS crash (BSOD)
    • MySQL service process crash
    • HDD bad sectors
    • other hardware or driver error (e.g. controller timeouts)
    I don't think it is wise to try to automatically repair the database without the user knowing. Repairing the database may end up with a database that is not corrupt but has missing data/tables/columns/indexes. That is why the suggested action is to first backup the raw database files, then try a repair, verify that everything is as it should and if there is something wrong restore from backup. In some cases repair is simply impossible and the only solution is a new database. Depending on the user's experience he may be able to extract whatever data is still accessible in the database (e.g. Channels, tuning details, schedules don't seem to be as easily affected as Programs) and import that into a new database.

    Perhaps a better solution would be to change MySQL to use InnoDB instead of ISAM. That way data is safe due to the transaction log (DBMS automatically repairs or rolls back). That is also one of the reasons why we have no such reports from users using MSSQL (it is always transactional)
     

    jameson_uk

    Retired Team Member
  • Premium Supporter
  • January 27, 2005
    7,258
    2,528
    Birmingham
    Home Country
    United Kingdom United Kingdom
    Perhaps a better solution would be to change MySQL to use InnoDB instead of ISAM. That way data is safe due to the transaction log (DBMS automatically repairs or rolls back). That is also one of the reasons why we have no such reports from users using MSSQL (it is always transactional)

    Perhaps we should just use Oracle ;)

    Anyway I think last time we discussed this there was a convincing argument against using InnoDB ?
     

    arion_p

    Retired Team Member
  • Premium Supporter
  • February 7, 2007
    3,373
    1,626
    Athens
    Home Country
    Greece Greece
    I do not remember that discussion (maybe you could give me a hint/link). Anyway I presume the biggest drawback of InnoDB is speed. MySQL is so much faster than most other RDBMSs because it uses ISAM by default which is not transactional (and thus much lighter on disk access: no transaction log and no immediate flushing of disk buffers)
     

    jameson_uk

    Retired Team Member
  • Premium Supporter
  • January 27, 2005
    7,258
    2,528
    Birmingham
    Home Country
    United Kingdom United Kingdom
    I do not remember that discussion (maybe you could give me a hint/link). Anyway I presume the biggest drawback of InnoDB is speed. MySQL is so much faster than most other RDBMSs because it uses ISAM by default which is not transactional (and thus much lighter on disk access: no transaction log and no immediate flushing of disk buffers)

    I wish I could... I remember having the discussion but can not find any reference to it (perhaps it was on IRC?)

    Is speed that much of an issue? it is probably very small in relation to the time taken in all the Object Relationship Mapping and looping code over the results once returned
     

    arion_p

    Retired Team Member
  • Premium Supporter
  • February 7, 2007
    3,373
    1,626
    Athens
    Home Country
    Greece Greece
    The difference in speed is when writing to DB, not reading/querying.
    I am not sure of the exact figure, I've read reports as low as 10% and as high as 50% :confused:
     

    Users who are viewing this thread

    Top Bottom