search

adamreichold / QMediathekView

Alternative Qt-based MediathekView front-end
GNU General Public License v3.0
17 stars 5 forks source link

thread '<unnamed>' panicked at 'invalid time' #23

Closed glitsj16 closed 1 year ago

glitsj16 commented 1 year ago

Hi, since a few days QMediathekView coredumps and I get the below output. It happens both on my main Arch Linux box and on an older Ubuntu machine, both running a build from git. Might this be a bad entree in the mediathek database? It always happens when QMediathekView tries to update its db, but I'm not sure if that's the case.

$ QMediathekView
thread '<unnamed>' panicked at 'invalid time', /home/glitsj16/.cargo/registry/src/github.com-1ecc6299db9ec823/chrono-0.4.22/src/naive/time/mod.rs:218:9
stack backtrace:
   0:     0x559192abf996 - <unknown>
   1:     0x559192a46f4e - <unknown>
   2:     0x559192a9d6f4 - <unknown>
   3:     0x559192ac0aaf - <unknown>
   4:     0x559192ac06af - <unknown>
   5:     0x559192ac1741 - <unknown>
   6:     0x559192ac1202 - <unknown>
   7:     0x559192ac116c - <unknown>
   8:     0x559192ac1141 - <unknown>
   9:     0x559192a45a52 - <unknown>
  10:     0x559192a49ef0 - <unknown>
  11:     0x559192a49e9b - <unknown>
  12:     0x559192a49e76 - <unknown>
  13:     0x559192a645c6 - <unknown>
  14:     0x559192a63d4b - <unknown>
  15:     0x559192a6354c - <unknown>
  16:     0x559192a71741 - <unknown>
  17:     0x559192a75baf - <unknown>
  18:     0x559192ac2025 - <unknown>
  19:     0x7fec42ce68fd - <unknown>
  20:     0x7fec42d68a60 - <unknown>
  21:                0x0 - <unknown>

When I noticed chrono-0.4.22 I patched the Cargo.toml to try chrono-0.4.23 but that didn't change anything. If I can provide any more info feel free to suggest what you might need. Now that my favo app for searching/watching German TV shows is broken I resorted to installing mediathekview's AppImage and that works fine with, I assume, the same mediathek database.

Best wishes for 2023!

adamreichold commented 1 year ago

Thank you for taking the time to report this. Seems I had too little time for TV. ;-)

Indeed, the issue is caused by entries with time specification like 45:23:00, i.e. the 46th hour of the day which chrono refuses to represent. I used the occasion to update the dependencies and swap out chrono for time which I wanted to do for a while now and finally, I made the parser resilient to invalid date and time values. (The entries will have default values, but they will be present and indexed.)

I pushed this to the master branch and the AppImage available here has been updated.