Whats the chances this build on FreeBSD has broken syncing? After updating to this version server, new items already in a sync list will transcode, but not download to players. Sync progress shows normally, then stops at waiting to be downloaded. Sync status on server does not show the down arrow, just a dark circle on the media. This failure is occurring on android and iOS players. Rest of PMS seems to work fine. Media in these sync lists worked flawlessly until this version.
1 Like
If I had this issue and was trying to work around it and/or determine if my setup was causing the issue, I would delete my iOS app, power cycle the phone, then install the latest Plex app from the App Store. I’d put the app into enhanced mode, then enable debugging on it, then enable its network and let it connect to PMS.
You could attach server and player logs here if you want someone to have a look for anything obvious.
Sync fails to download media after conversion on both iOS and Android. Have uninstalled and reinstalled the app on both systems multiple times. Seems the issue is with the FreeBSD build of PMS. Also have the same version running on MacOS and sync is working fine.
Okay you were some steps ahead of me. Do you know the last PMS version before this issue on FreeBSD? Do you want to upload logs or just leave it for now?
Two updates rolled out for FreeBSD (running in a Jail on FreeNas) within a couple days of each other. The last version I know was working is 1.18.3.2156-349e9837e. I think the wheels fell off with version 1.18.4.2164-2aa83397b, but can not confirm. Version 1.18.4.2171-ac2afe5f8 dropped a couple days later and sync has not worked since on FreeBSD. I maintain version parity on the MacOS PMS and it is running 1.18.4.2171 which is syncing just fine.
Plex Media Server Logs_2019-12-24_09-57-33.zip (5.6 MB)
The Shield version is broken too, for exactly the same reasons you stated above. Did the same, uninstalled, installed, deleted all offline content, still stuck on “Waiting to download”. I too also noticed this problem from 2164, and same problem on 2171. Synology version of 2171 is syncing fine. Also crossposted here: Sync stuck on "Waiting to Download" on 1.18.4.2171
@bgman62_yahoo.com I took a look at your logs just now, but it’s worth saying the complexity of your LAN is beyond my experience.
That being said, we shouldn’t expect a lot of errors in your com.plexapp.system.log, as it’s more the housekeeping part of your server. What I saw were a lot of:
2019-12-24 04:19:56,745 (802619900) : INFO (agentservice:553) - Error parsing search results.
-which repeats every second until-
2019-12-24 04:23:12,663 (802619900) : INFO (agentservice:553) - Error parsing search results.
and one instance of a 403 Forbidden:
2019-12-24 07:55:08,214 (80ae59400) : ERROR (networking:196) - Error opening URL 'http://127.0.0.1:32400/library/metadata/68472/tree'
return HTTPRequest(self._core, url, data, h, url_cache, encoding, errors, timeout, immediate, sleep, opener, follow_redirects, method)
File "/usr/local/share/plexmediaserver-plexpass/Resources/Python/lib/python2.7/urllib2.py", line 473, in error
File "/usr/local/share/plexmediaserver-plexpass/Resources/Python/lib/python2.7/urllib2.py", line 556, in http_error_default
raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
HTTPError: HTTP Error 403: Forbidden
Moving on to your Plex Media Server.log, unfortunately it was in VERBOSE mode. So it makes it hard to work with. Please disable that. Using grep and sed, I removed what I could and found issues with Plex Relay repeatedly dying. I’ll paste a partial sequence of events found searching for the word relay so this not all the lines
Dec 24, 2019 08:24:34.202 [0x814022000] DEBUG - [PlexRelay] Authenticated to 172.105.3.158 ([172.105.3.158]:443).
Dec 24, 2019 08:24:34.435 [0x81384a000] ERROR - [PlexRelay] kex protocol error: type 7 seq 11
Dec 24, 2019 08:24:34.950 [0x814022000] INFO - [PlexRelay] Allocated port 3881 for remote forward to 127.0.0.1:32401
Dec 24, 2019 08:29:59.227 [0x813e1c000] DEBUG - [PlexRelay] Transferred: sent 10956, received 5668 bytes, in 325.0 seconds
Dec 24, 2019 08:29:59.227 [0x814aeb000] DEBUG - [PlexRelay] Bytes per second: sent 33.7, received 17.4
Dec 24, 2019 08:29:59.228 [0x80bb74400] DEBUG - Jobs: '/usr/local/share/plexmediaserver-plexpass/Plex Relay' exit code for process 79555 is 255 (failure)
Dec 24, 2019 08:34:30.089 [0x815da4e00] DEBUG - Relay: cleaning up inactive relay connection to 172.105.3.158
That sequence repeats 4 or 5 times in your logs over an hour. That’s somewhat abnormal.
Also I’m seeing a lot of sync going on but also seeing over 100 of these:
Dec 24, 2019 09:13:47.053 [0x814aec400] WARN - Held transaction for too long (../Statistics/StatisticsManager.cpp:248): 0.101562 seconds
Dec 24, 2019 09:14:17.498 [0x814889000] WARN - Held transaction for too long (../Statistics/StatisticsManager.cpp:248): 0.117188 seconds
I don’t know really know why the sync is stopping or not working now. If you can eliminate the possibility of the jail environment being an issue, then the sync problem seems outside of your ability to fix, because the logs don’t indicate to me anything critical like a database corruption.
I’d roll back to a more stable version now that you’ve reported this well, if that makes sense in the context for your advanced LAN. Doing so would hopefully solve the PlexRelay issue, giving you a more stable network. It’s possible the dying relay is affecting your ability to sync.
good luck!
Thank you for analyzing the logs and explanation of events. i have two active NICs on the server running FreeNas and along with using a jail for Plex, yet another v-net is introduced, FreeNas does some interesting stuff with networking i’m still learning about though no changes were made when sync stopped working. I’ll try to eliminate some of the network complexity and see what happens.
might be a few days, but I’ll post the results. thanks for the help and notes where to look in the logs.
You’re welcome. Glad to offer whatever context I can, but I didn’t mean to suggest it’s your setup when your OP talked about it working before. The best workaround may be to roll back to the last PMS version that was good for your system. I think you’ve enumerated the issue well enough for the devs to make note of it.
Thanks again, and Happy New Year!
Wanted to report back that I did roll back to the last version sync worked (1.18.3.2156-349e9837e) and sync is indeed working again. All three devices started syncing as expected.
I don’t want to be stuck at an old version and miss any new features from current versions. If I find time, I could try to reconfigure my network on the FreeNas box to see it makes any difference with newer releases of Plex.
Odd 1.18.4 doesn’t have changes that would touch this area… at least not directly 
That said apart from:
Dec 24, 2019 09:13:47.053 [0x814aec400] WARN - Held transaction for too long (…/Statistics/StatisticsManager.cpp:248): 0.101562 seconds
Dec 24, 2019 09:14:17.498 [0x814889000] WARN - Held transaction for too long (…/Statistics/StatisticsManager.cpp:248): 0.117188 seconds
I also don’t see many info in the logs, and I also don’t see issues testing at my side with same version and the “Desktop App” for macOS.
Could you please try this again? disable “VERBOSE” and re-post the logs?
1 Like
I reinstalled 1.18.4.2171-ac2afe5f8 (free BSD) turned on debug logging and set up two new sync sessions with two different TV shows. one is to iOS and the other to Android. I also made a minor change to the network configuration using a different NIC.
Same result as OP. conversion takes place, the devices see the new episodes available in sync->manage, but download never starts.
Logs enclosed.
Thanks.
Plex Media Server Logs_2020-01-07_23-32-08.zip (2.4 MB)
FYI;
After posting this, I downgraded to 1.18.3.2156-349e9837e, and restarted the sync on both devices, they began downloading the episodes.
1 Like
@mikec_pt, how about for the Nvidia Shield then? PMS 2171 on the Shield is showing the same error
It could be related, but best attach logs.
Looking at the logs @bgman62_yahoo.com provided now see if anything looks suspicious.
I took a cursory look through the logs that @bgman62_yahoo.com has provided, I am currently experiencing the same issue on my end. It looks like there is a Soci exception that is being thrown shortly after the server attempts to send the files to the synchronize device.
I can get some additional logs if they help.
1 Like
I noticed that too and might explain the reason actually has there was a soci lib bump recently, I’m creating an internal bug now but that is likely related.
1 Like
Logs posted 17 days ago Sync stuck on "Waiting to Download" on 1.18.4.2171
Hello @mikec_pt like @philiptruong I posted my logs in an other topic. If it can help.
sorry for the late reply @djpoulet yeah you’re logs also show: Dec 28, 2019 18:35:28.638 [10111] ERROR - Soci Exception handled: Value at position 7 was set using a different type than the one passed to get() so looks like the same regression, we are working on a solution.
2 Likes
