Within the past couple months, I’ve been having three issues that seem to be related to streaming or queuing music, two are in the title of this request, because I think I was able to capture both in the recent logs.
Occasionally, a song will play and then will restart from the beginning, usually at the 25% mark give or take, but sometimes it repeats the whole song when there is another next in queue.
Occasionally, playback produces a loud distorted sound, like an old record scratch (or worse).
Probably not in this set of logs, occasionally playback skips the next song or several of the next songs. I thought my settings were set to pre-cache the next several songs.
Logs:
Upload description: awilling
Additional information:
Willing to provide additional information as needed
Its not something I know how to trigger, and it doesn’t happen often, hence the lengthy logs. I suppose those are silver linings.
The record scratch occurred on a song with “Dumbledore” in the name, at time 16:19:xx, or at least that’s what the “PlexMediaServer” log says; the transcoding logs are unintelligible to me.
For the log mentioned, I’m not sure what I’m looking for, though I see a few “ERROR” codes that say:
“ClientProfileExtra: music transcode target already exists for streaming http”
…and a few that say:
“[TranscodeOutputStream] Streaming Session 0x1549be0e2c68 appears to have died from under us”
I apologize. These logs are hard to parse for me, and must be difficult on your end, too. I didn’t provide enough information.
If I toggle the debug setting, will it flush the logs? I can set aside some time for testing, and could toggle debug (flush the logs?) every 15 minutes and can try to pinpoint the exact times from within that. Would that be more helpful?
The important here is the Plex logs that line “appears to have died from under us” means that transcoding crash or fails inside Plex server so it’s there’s to look for details about why it crash.
Thanks for your patience. I had both the skip/hiccup issues and the record scratch occur between 4:00pm and 5:05pm yesterday. I uploaded another set of logs, and they may be days worth again, but please do your best to ignore that and just skip to the time above.
Both instances (yesterday and the issue from March 18, too) occurred shortly after connecting to wireless Android Auto in my car, if that helps. I hope it explains why my own debugging seems flaky and imprecise: I’m driving when the problem happens and and focusing on driving.
How can I privately send you the plex logs for the same time period? EDIT: I tried to attach it via email. I’d prefer it not show up in this public thread.
Anyway the logs are strange there’s network cut it seems but the retries do not work Plex seems to reject them.
[Req#e326c/Transcode] Denying access due to session lacking permission to transcode key /library/metadata/39924
Even more strange is that plex says: handleStreamWrite code 104: Connection reset by peer but Symfonium detect an EOF so the connection is not properly closed and plex sees something different.
Do you use a proxy? Can it be an issue with your router?
I’m not sure if my March 23 email response was added to the thread; looks like it was not, so I’m copy/pasting it below:
I don’t use a proxy. I doubt it’s my router; it only seems to occur with transcoding, or it’s otherwise new. It didn’t happen in February, for example, and my router hasn’t even reset in the past few months.
Plex did have an update in the past 3-4 weeks. Might be on the Plex side.
I’m going to test by switching OFF transcoding (on the Symfonium settings), and just using the original file size & type. I’ll see how that goes for a few days.
Since March 23, I’ve had the “Mobile Maximum Bitrate” setting in the “Decoding and Transcoding” menu set to “Original” (and “Original” has always been the setting for wifi bitrate). I haven’t encountered any of the kinds of problems I originally mentioned from a couple weeks ago. I’m going to change the mobile bitrate setting back to 128 kbps and see if the problems resume.
The playback problems resumed within hours of switching on the 128 kbps transcoding option. One time, a track restarted at the ~20% mark four times, and then refused to even start; I had to click to the next track.
A couple days ago I switched on the transcoding option in Plexamp. I haven’t witnessed a similar error with it, yet.
So, playback works fine as long as Symfonium isn’t transcoding. As soon as I ask Symfonium to transcode, the problems resume. I’m willing to try different settings or configurations if you have any recommendations.
