Server Version#: 1.18.1.1973
Player Version#: 4.8.3
Hello,
I have been having issues with syncing my music library from about mid October, after the 1846/1913 update, which I’ll break down over this post and supply logs and further information as requested by support.
Server Details: Arch Linux Host using Dockerhub image -> linuxserver/plex [public stream]
Sync Job Details: Entire Music library to iPhone 7 Plus on iOS 13 using the most up-to-date version of the Plex app
Sync Job Issue: All music added after the big update will not sync
My initial analysis/diagnosis/troubleshooting: Tail followed the “Plex Media Server.log” and noted that files were being looked for at “/config/Library/Application Support/Plex Media Server/Cache/Transcode/Sync+/xxxxxxx/xx” and while observing the log creation, I was also observing the creation of folders and transcoded files within that directory structure. Following this, I did a quick comparison and noted that from the logs, the server was looking for/in directories that did not exist, they were all named differently in the actual …/Sync+/xxxxxxx/xx/ path that the server was creating in real time.
Based on the above there seems to be a disconnect between the transcode job and the sync scheduler in terms of the expected path which is odd and is beyond my ability to resolve.
Esoteric bonus problem but not a major concern: One of the newly added albums is already mp3 but gets transcoded again? What’s with that?
Update. Syncing isn’t perfect, it still keeps trying to download things over and over, despite them being on the device… but at least the songs make it onto my device and I can listen to them on my no-wifi plane trips.
Server version: 1.18.4.2171
iOS App Version: 6.7.2
Due to the ongoing CI build issue related to the docker hub /r/linuxserver/plex release, I am out of sync between Plex Server and iOS app, and this exact issue is happening again. I suspect when the Plex Server catches up this will resovle itself. Will keep monitoring.
To reiterate: once again, the new music files get transcoded in the background, and when I open the app to pull the files down it goes through and fails on all of the downloads, with the Plex Media Server.log file stating that the file doesn’t exist - because it doesn’t at the path it is referencing, however the temp file is there. Tried just simply restarting and then failing that, clearing the temp transcode and restarting the server to no effect.
The worst part about it is the iPhone 7+ is getting a bit long in the tooth and having to fail 125 downloads each time I open the app is incredibly tedious, as the app grinds close to a halt, adding insult to injury is the aggressive background app closing in iOS 13. Not a good combo. Really hoping that a new build of Plex can make it through to the docker hub.
(P.S. I realise I am effectively talking to myself at this point, but at least the data will be here for anyone to Google in the future)
When the LSIO problem surfaced, they reached out to me.
We figured out a way to go forward which not only works for them but for everyone else who wishes to build their own docker and be able to update PMS after everything is built and running.
While I cannot help with the particulars of docker, I am willing to look at and see what errors you’re having. I’ve seen cases where the LPE (local path evaluator) fails and causes the sync to fail (almost a guarantee it will cause failure).
If you can verify DEBUG logging ON, Verbose logging OFF, and capture a Sync operation, I will look.
I ask two steps:
Put something in the queue
Pull from the iOS device. (i also have iOS here so can track along with you step by step)
30 seconds after it’s all finished,
Download the logs ZIP (settings -server - troubleshooting - download logs)
I am fine to create another individual download task, but on my iPhone, I can’t do that without the 129 attempting to come down, and the only way to start fresh would be to clear all download tasks and lose the 9000+ songs I have already downloaded with no assurance that I’ll be able to pull them back down again until future time/release x.
Just wanted to clarify your instruction and confirm if you’re ok to see all those additional logs again AND the new download task? Or
If you would like me to clear my current failing task first and then attempt a new one. Or
Option 3 I have not been able to think up.
P.S. The trans-coded files are (or rather were) on my hard drive in the directory, just not in the “00/0000.mp3” path that the sync job was looking for, it was instead, for example’s sake in “01/0001.mp3”.
Apologies for the delay, I was being a little selfish and hoping that the update to 1.18.6.2368 would resolve everything - it didn’t - and I’ve attached logs in case you were interested. There were new tracks added to the Sync job which is just my entire “Music” library between versions and even they didn’t come down. 1.18.6.2368 Update - Plex Media Server Logs_2020-02-11_08-52-15.zip (2.0 MB)
In any case, I removed all sync tasks through PMS, and then reinstalled Plex on my iPhone - this was what I assumed was the only only way to actually remove the files from the phone but resetting cache in advanced works, which I found out through doing this the second time since the debug logging wasn’t on for the first run - and made a new sync task for one of the albums that was added after sync stopped working, and before 1.18.6.2368, just for posterity.
Performed as above, debug logging on, verbose off, and waiting about 30 seconds after the iOS app is “done”. I also had a tail of the logs going to make sure any related activity had ceased. The album synced to my phone, no sweat and all files could be place. Please find the logs attached here. One New Sync - Plex Media Server Logs_2020-02-13_01-26-41.zip (697.5 KB)
Side note - It’s funny that after every fresh restart PMS refers to a specific dead sync list, but there were none in my PMS at the time that log was made - these are the lines in question:
Feb 13, 2020 01:21:42.024 [0x7f38a77fe700] WARN - Sync: sync list 35147786 belonging to user 1 (lateparty) has died of old age, ignoring
Feb 13, 2020 01:21:42.026 [0x7f38a77fe700] INFO - Sync: downloaded 1 sync list(s) with 0 sync items(s): 0 new, 0 updated, 0 deleted
P.S. The reason for my hesitation is, syncing 9000+ songs to a device with MDM and a maximum screen idle time of 5 minutes does not spark joy. Further, if I take a break for any longer than say 20 minutes in the process, the rest of the songs that didn’t come down just fail on future attempts to finish it.
You might just need to turn off the Auto-Lock reloading that many files. 9000 files @ 3 MB average = 27 GB. Assuming 27 GB @ 90 MB/sec (uninterrupted average transfer speed) will take somewhat over 5 minutes to complete. Most devices associate at 877 Mbps which is closer to 80 MB/sec in practice.
For security purposes no timeout is disabled due to the corporate profile I have opted in to having on my phone for the joy of email.
Due to Plex transcoding sequentially on my low power NUC and needing to transcode almost everything, it takes about 1.5-3 seconds per song, so let’s put that at an average of 2 seconds, so 18,000 seconds just for the transcode, but that’s ok I let that happen overnight and just don’t open the Plex app. But then “transferring” is more than just a file dump, watching on the dashboard I see every song pass through, and validate which is again about 0.45-1 second per song at least because regardless of my NUC being on a gigabit line with a 970 Evo, and my iPhone being connected via AC right near the router, the sequential, validation aspect kicks in, and it takes about 7500 seconds~ I.e. 2 hours. With a mandatory 5 minute lock screen time out, I trust you to do the math on the amount of taps and attention required
Definitely, but in the past when I try to do the slowly growing option PMS starts to become incredibly unresponsive every time I go to edit the job and it is ultimately/relatively less frustrating to just keep tapping or unlocking my phone.
It’s ok, I just thought I’d lay it out that it’s not that straight forward, and explain why it’s something I prefer to avoid doing. Generally, too bar the exception of literally the bug being worked on in this thread it’s not something I need to do too often either!
@ChuckPa Hi Chuck, just wanted to check in and see if it’s safe to proceed with a mass library sync or continue holding off until there is a relevant update. I haven’t been keeping track of PMS updates of late due to work commitments.
