With the last Plex server update, it decided on its own, without any modification on my side to update libraries. Everything is now tagged added 8 days ago, which is very nice, and many posters have been changed without a chance to be noticed. Thank you dev team this is really a major milestone achievement.
Running: 1.27.2.5929
Any comment, others having same issues?
Do you mean refresh metadata? We would need to see the server logs to see why it decided to do that. Off hand I can only think of the scheduled task to refresh every three days but there may very well be a bug
In addition to BigWheelās responseā¦ it might also be helpful to understand your setup.
e.g.
- Is your media stored on the machine hosting your Plex Media Server or on an external, network or remote/cloud drive?
- Have you configured your server to automatically / regularly scan for changes?
See:Settings>[Server Name]>Library>Scan my library automaticallyandScan my library periodically - Have you configured your server to empty its trash whenever a scan is completed?
See:Settings>[Server Name]>Library>Empty trash automatically after every scan
If your server performs an automatic scan and the external drive takes too long to spin-up / react, this can result in Plex considering those items gone and deleting them from your library. During a subsequent automatic/periodic scan, the files might get picked up again ā Plex will them consider to be new items.
If you have such a configuration itās good practice to disable Empty trash automatically after every scan.
1 Like
Thanks @BigWheel and @tom80H to jump into this thread.
Media is stored on a NAS that is always on. It is out of question that NAS would have been offline when Plex has started. As a matter of fact the HTPC on which Plex is installed is most of the time off and started whenever it is needed.
With this last version, Plex takes a long time to be on line because it āupdates libraryā before. A window pops-up at every Plex server startup stating that which never occured before.
It broke collections as well.
Here are the logs
Plex Media Server Logs_2022-07-21_08-10-55.zip (331.0 KB)
In the meantine Scan every xx hours has been deactivated as well as Empty trash.
It turns out that I have a second Plex server on a windows machine as well that is the replica of this one. How could I import the database of this server to the broken one?
Thank you
Nobody in Plex employees having the willingness to troubleshoot and help?
EDIT:
The second Plex instance running at the same version level, windows as well, does not have this behaviour.
It has to be noticed, that EACH time Plex server is launched, a windows pops up stating updating libraries while nothing as changed. It lasts 10ā or so
Your DB is corrupted
Jul 21, 2022 08:09:52.352 [9800] ERROR - SQLITE3:0x833f6cfe, 13, os_win.c:44993: (112) winWrite1() - Espace insuffisant sur le disque.
Jul 21, 2022 08:09:52.352 [9800] ERROR - SQLITE3:0x833f6cfe, 13, statement aborts at 17: [INSERT INTO vacuum_db.āstatistics_mediaā SELECT*FROM"main".āstatistics_mediaā] database or disk is full
Jul 21, 2022 08:09:52.640 [9800] ERROR - SQLITE3:0x833f6cfe, 13, statement aborts at 1: [VACUUM] database or disk is full
Jul 21, 2022 08:09:52.656 [9800] ERROR - Exception thrown during migrations, aborting: sqlite3_statement_backend::loadOne: database or disk is full
Jul 21, 2022 08:09:52.674 [9612] ERROR - LPE: unknown item 8759.
Jul 21, 2022 08:09:52.674 [9612] ERROR - Versions: failed to generate query for path library://767e6a7f-3cfc-4e2f-9462-65891574e1e6/item/%2Flibrary%2Fmetadata%2F8759
Jul 21, 2022 08:09:52.674 [9612] ERROR - Versions: skipping items for generator 2579: unable to generate version set query
The first errors imply you are out of disk space on the drive the DB resides on. It looks like it tried to update when you applied the last upgrade but it didnāt have the space to do so.
Clear some space on the drive
restart the Plex server and leave it sit for 10 mins - in case it still wants to upgrade.
restart it again and If still issues follow the below.
https://support.plex.tv/articles/repair-a-corrupted-database/
2 Likes
Thanks very much to help on this matter. The partition on which db is stored says 174GB are free over 374GB. Plex executables are installed on c:\ partition. It currently reports 9.4Gb free over 55Gb. I ran a prama command on com.plexapp.plugins.library.db. No errors. I started Plex server again and updating libraries still pops up for 15ā roughly.
This is really the first time I see this message at startup. The second Plex server instance on a another PC is running fine.
New server logs are attached in case it delivers some insights. Message related to disk full or database corrupted is still there. Shall continue with VACCUM command and REI!NDEX? Or shall I try to āOptimizeā database ?
Plex Media Server Logs_2022-07-31_19-00-12.zip (300.2 KB)
So, did you clear some space on the drive the database is stored on?
Plex folder size is 176GB, free space on the same partition is 174GB. Why would I free space, there is plenty of space, isnāt it?
Edit: corrected typo Gb to GB
what filesystem is this partition using? It is a local or remote drive?
How large is the com.plexapp.plugins.library.db file?
Please urn on debug logging on your server when providing logs for review. I believe the space the log is referring to is your wherever your windows temp folder is. Plex will use this during the vacuum process. How large is the actual Plex database, not the entire folder?
Local SSD drive, 23,1GB.
NTFS
EDIT: Added updated logs
Plex Media Server Logs_2022-08-01_14-27-16.zip (302.7 KB)
In order to try to solve this issue, I tried VACUUM; command using Plex SQL Lite.exe. Same message as in the log is reported: āDatabase or disk is fullā. Well disk is not full as I reported above, Iāve no clue on which direction to take.
Did you turn on debug logging? I donāt see it in your logs.
You need to enable debug level logging and restart Plex Media Server. Wait for Plex to fully start, usually 2 - 3 minutes, then scan your libraries and pull the server log files.
Settings ā Server_Name ā General + Show Advanced
Sorry I thought the option was activated. Attached are the new logs.
Plex Media Server Logs_2022-08-02_14-26-58.zip (448.6 KB)
Whenever the Plex server is started, this window is displayed for 25ā or so. Plex is online after this time. Nothing has changed in any librairies.
Why VACUUM; command reports āDatabase or disk is fullā whereas there is plenty of disk space?
Iāve got the feeling this is the root cause of the issue.
Thanks for the updated log files.
It seems SQLITE3 uses temp space as a working space (source). If it is full, or exceeds a quota limit, you could see the āinsufficient spaceā messages.
For the username that runs Plex, what is the setting for TMP and TEMP? C:\set should display them. Any chance those locations are short of space or close to a quota limit?
From Plex Media Server.log:
Aug 02, 2022 08:54:41.955 [8404] DEBUG - BPQ: [Starting] -> [Processing]
Aug 02, 2022 09:02:54.377 [5904] INFO - Vacuuming database.
Aug 02, 2022 09:17:34.071 [5904] ERROR - SQLITE3:0xd1a103c6, 13, os_win.c:44993: (112) winWrite1() - Espace insuffisant sur le disque.
Aug 02, 2022 09:17:34.071 [5904] ERROR - SQLITE3:0xd1a103c6, 13, statement aborts at 26: [INSERT INTO vacuum_db.'statistics_media' SELECT*FROM"main".'statistics_media'] database or disk is full
Aug 02, 2022 09:17:34.438 [5904] ERROR - SQLITE3:0xd1a103c6, 13, statement aborts at 1: [VACUUM] database or disk is full
Aug 02, 2022 09:17:34.454 [5904] ERROR - Exception thrown during migrations, aborting: sqlite3_statement_backend::loadOne: database or disk is full
Aug 02, 2022 09:17:34.460 [8404] ERROR - SQLITE3:0xd1a103c6, 1, no such column: metadata_items.edition_title in "select metadata_items.id as 'metadata_items_id', metadata_items.library_section_id as 'metadata_items_library_section_id', metadata_items.parent_id as 'metadata
Aug 02, 2022 09:17:34.461 [8404] ERROR - Thread: Uncaught exception running async task which was spawned by thread 8540: sqlite3_statement_backend::prepare: no such column: metadata_items.edition_title for SQL: select metadata_items.id as 'metadata_items_id', metadata_items.library_section_id as 'metadata_items_library_section_id', metadata_items.parent_id as 'metadata_items_parent_id', metadata_items.metadata_type as 'metadata_items_metadata_type', metadata_items.guid as 'metadata_items_guid', metadata_items.hash as 'metadata_items_hash', metadata_items.media_item_count as 'metadata_items_media_item_count', metadata_items.title as 'metadata_items_title', metadata_items.title_sort as 'metadata_items_title_sort', metadata_items.original_title as 'metadata_items_original_title', metadata_items.studio as 'metadata_items_studio', metadata_items.rating as 'metadata_items_rating', metadata_items.audience_rating as 'metadata_items_audience_rating', metadata_items.rating_count as 'metadata_items_rating_count', metadata_items.tagline as 'metadata_items_tagline', metadata_items.edition_title as 'metadata_items_edition_title', metadata_items.summary as 'metadata_items_summary', metadata_items.content_rating as 'metadata_items_content_rating', metadata_items.content_rating_age as 'metadata_items_content_rating_age', metadata_items.'index' as 'metadata_items_index', metadata_items.absolute_index as 'metadata_items_absolute_index', metadata_items.duration as 'metadata_items_duration', metadata_items.user_thumb_url as 'metadata_items_user_thumb_url', metadata_items.user_art_url as 'metadata_items_user_art_url', metadata_items.user_banner_url as 'metadata_items_user_banner_url', metadata_items.user_music_url as 'metadata_items_user_music_url', metadata_items.user_fields as 'metadata_items_user_fields', metadata_items.originally_available_at as 'metadata_items_originally_available_at', metadata_items.available_at as 'metadata_items_available_at', metadata_items.expires_at as 'metadata_items_expires_at', metadata_items.refreshed_at as 'metadata_items_refreshed_at', metadata_items.year as 'metadata_items_year', metadata_items.added_at as 'metadata_items_added_at', metadata_items.created_at as 'metadata_items_created_at', metadata_items.updated_at as 'metadata_items_updated_at', metadata_items.changed_at as 'metadata_items_changed_at', metadata_items.resources_changed_at as 'metadata_items_resources_changed_at', metadata_items.tags_genre as 'metadata_items_tags_genre', metadata_items.tags_collection as 'metadata_items_tags_collection', metadata_items.tags_director as 'metadata_items_tags_director', metadata_items.tags_writer as 'metadata_items_tags_writer', metadata_items.tags_star as 'metadata_items_tags_star', metadata_items.deleted_at as 'metadata_items_deleted_at', metadata_items.tags_country as 'metadata_items_tags_country', metadata_items.extra_data as 'metadata_items_extra_data' from metadata_items where guid=?
Just check all your drives you have access to from that machine and make sure you have space on all of them equal to at least 2x the size of your database.
Thank you. I changed TMP and TEMP path to another partition where there is plenty of space, closed session and reopened it. c:\set confirms the change. Then VACUUM; command has been run without any hickups. It took 1h and 3/4 to get Plex back on line.
First M2 250GB disk has two partitions: C: (system) has more than10GB free space over 55GB. E: drive than 158GB over 182GB. It is used for Plex backups and now for TMP and TEMP folder. Second SSD 500GB has only one partition: it is where most applications are installed including Plex server
During the VACUUM process I could not see any space consumption, which is very strange. The bottom line, changing the path of TMP and TEMP cured the problem. So big thank you to @FordGuy61 but also to all of you who volunteered on this case.
I now have to upload database of my second Plex server to get things in order.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
