Why is this tagged Server-Linux-ARM (Armv8 cpu class) ?
This tag must be manually selected.
I need log files to proceed. No more guesswork.
So which hardware are you using?
Are you using the binary for ARM on a Intel Xeon CPU?
I’m sure it was [server-linux] when I started the topic O_o
Maybe my fault, sorry.
Raspberry Pi is a client, sorry if that wasn’t clear.
I don’t think you both need to waste more time on me, I got all I wanted — I need to reinstall Plex and start from nothing. Good sign to migrate to SSD at one.
Thank you all.
You still have the option to try the repair. It may still be faster than recreating all libraries from scratch – even if it involves copying hundreds of GBs.
Ok, I’ll try follow appropriate instructions before “burning it down” 
Thanks
This is just anecdotal, but I had a similar issue a few months ago. I have a relatively small library (a few hundred movies, a few tens of TV shows, a couple hundred albums) and my database reflects that, normally hanging around 40 MB in size. For no apparent reason, over the course of a day or two, it ballooned to ~300 MB. I only noticed this because the manual database optimization I perform after any media addition/deletion started taking minutes to complete instead of a few seconds.
I ran sqldiff against my then-current database, comparing it to the most recent backup of normal size. The largest difference was that the statistics_media table had had tens of thousands of new entries added (the backup had ~1400 entries while the current had ~75000). Investigating further using DB Browser for SQLite, I had a look at the table. I noticed that there were many new entries being added from a device_id I didn’t recognize (from the devices table) where the duration was 0); I can’t recall for certain, but I believe the account_id was null.
So, knowing I had a recent backup, I stopped Plex Media Server and whacked all the “suspicious” looking entries from the statistics_media table. After doing so, the database returned to its normal size. Plex operated normally after starting it again.
So, if you’re resigned to burn it down and start over, it may be worth having a look at your database beforehand to see if you have a similar situation.
Thank you for answer! It’s hard to analyse database now, but I have thousands of such entries in log files:
Jul 16, 2020 16:30:53.698 [0x7f747caf5700] DEBUG - Play progress on 43994 ‘Моя ужасная няня’ - got played 2434000 ms by account 0!
Jul 16, 2020 16:30:53.698 [0x7f747caf5700] DEBUG - [Now] User is (ID: 0)
Jul 16, 2020 16:30:53.698 [0x7f747caf5700] DEBUG - [Now] Device is Konvergo (PlexMediaPlayer).
Jul 16, 2020 16:30:53.698 [0x7f747caf5700] DEBUG - [Now] Profile is Konvergo
Jul 16, 2020 16:30:53.698 [0x7f747caf5700] DEBUG - [Now] Updated play state for /library/metadata/43994.
Jul 16, 2020 16:30:53.698 [0x7f747caf5700] DEBUG - Statistics: (wq2spgjs1o9j655ewtphqia4) Reporting active playback in state 1 of type 1 (scrobble: 0) for account 0
I think, our issues are similar. Unfortunately, I’ve noticed that too late, because I have no habit to check free space on system HDD of my server.
UPD: well, I have a lot of rows with null id in this table, hard to say how much, it will take time to perform “select COUNT(*) from statistics_media”. I think this is definitely a bug,
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
