Server Version#: 1.40.1.8227 (QNAP - PlexMediaServer-1.40.1.8227-c0dd5a73e-armv7neon.qpkg)
Player Version#: N/A
This problem started fairly recently; within the last few months at least. Running Plex and SMB sharing the directories is literally the only thing the NAS does for me, and has been fine for several years. My collection is about 10TB, though, and I have recently added a big chunk of TV media to it (Something like 400GB).
I just ran the DBRepair.sh tool from @ChuckPa, which exited with an “Unexpected EOF” after the “Automatic Check., Repair/optimize, & Index successful”.
BusyBox v1.01 (2024.02.19-03:31+0000) multi-call binary
Usage: readlink
Displays the value of a symbolic link.
Plex Media Server Database Repair Utility (QNAP)
Version v1.05.01
[2024-03-24 08.48.16] Automatic Check,Repair,Index started.
[2024-03-24 08.48.16]
[2024-03-24 08.48.16] Checking the PMS databases
[2024-03-24 08.48.23] Check complete. PMS main database is OK.
[2024-03-24 08.48.27] Check complete. PMS blobs database is OK.
[2024-03-24 08.48.27]
[2024-03-24 08.48.27] Exporting current databases using timestamp: 2024-03-24_08.48.16
[2024-03-24 08.48.27] Exporting Main DB
[2024-03-24 08.48.39] Exporting Blobs DB
[2024-03-24 08.56.00] Successfully exported the main and blobs databases. Proceeding to import into new databases.
[2024-03-24 08.56.00] Importing Main DB.
[2024-03-24 08.56.30] Importing Blobs DB.
[2024-03-24 08.56.54] Successfully imported databases.
[2024-03-24 08.56.54] Verifying databases integrity after importing.
[2024-03-24 08.57.00] Verification complete. PMS main database is OK.
[2024-03-24 08.57.01] Verification complete. PMS blobs database is OK.
[2024-03-24 08.57.01] Saving current databases with '-BACKUP-2024-03-24_08.48.16'
[2024-03-24 08.57.01] Making repaired databases active
[2024-03-24 08.57.01] Repair complete. Please check your library settings and contents for completeness.
[2024-03-24 08.57.01] Recommend: Scan Files and Refresh all metadata for each library section.
[2024-03-24 08.57.01]
[2024-03-24 08.57.01] Backing up of databases
[2024-03-24 08.57.01] Backup current databases with '-BACKUP-2024-03-24_08.57.01' timestamp.
[2024-03-24 08.57.03] Reindexing main database
[2024-03-24 08.57.11] Reindexing main database successful.
[2024-03-24 08.57.11] Reindexing blobs database
[2024-03-24 08.57.13] Reindexing blobs database successful.
[2024-03-24 08.57.13] Reindex complete.
[2024-03-24 08.57.13] Automatic Check, Repair/optimize, & Index successful.
[2024-03-24 08.57.13] Unexpected EOF / End of command line options. Exiting. Keeping temp files.
[2024-03-24 08.57.13] Unexpected exit command. Keeping all temporary work files.
Quick side note - I had to change the script params for df to remove the POSIX mode flag as it was returning an error when I ran it.
The sh file, but Windows doesn’t “immediately” break the file - it will replace LF with CRLF if you open it in Windows Notepad and then save it, but it doesn’t just do that automatically. I have a proper text editor, so even if I did the intermediate step of looking at/editing the file before uploading it to the NAS, it wouldn’t have broken the file.
When running the unedited script, I got an error that the option ‘P’ is invalid; I get the same error if I try to do it directly from the CLI:
# df -P
df: invalid option -- 'P'
BusyBox v1.01 (2024.02.19-03:31+0000) multi-call binary
Usage: df [-hmkc] [FILESYSTEM ...]
Print the filesystem space used and space available.
Options:
-c correct formatting error
-h print sizes in human readable format (e.g., 1K 243M 2G )
-m print sizes in megabytes
-k print sizes in kilobytes(default)
EDIT:
Just tested and any call to the readlink function results in that output on my NAS, even if there’s no symlinks involved. I created a test script at /root/test.sh and was able to replicate the output. Seems there’s something different about my NAS than the one you’re using to test. Happy to get you creds on Wireguard to let you poke around if you want.
Yeah I don’t even have an /etc/os-release or anything matching “release” in it. Which df/date show the same output adjusted for timezone, but definitely a different version of BB.
The DLNA server is a known memory leaker which they’ve never been able to solve. (It’s disabled by default for that reason. Daily restart is the only cure)
Heavy uses of memory, which will cause QTS to kill the pids can come from:
– Intro detection
– Credit detection
– Transcoder temp directory being set to /tmp and then running out of space.
There has been a great deal of work done to the scanner recently.
Is it possible? YEP
I’ll get started on a session where I monitor memory usage while building a new library
I built up a whole server (about 15,000 files worth) on my 1 GB RAM TS-128A.
Intro and Credit detection are still running (it will take a while on the machine) but so far I have no indication of failure
