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.
I don’t have any logs since early April, though I can offer some additional anecdotes and have a couple additional questions. I should preface this with a comment that troubleshooting this isn’t my priority, and I don’t ask it to be yours, either.
The transcoding issues seem to persist into Symfonium 10. They’re still relatively uncommon, occurring in my use cases almost exclusively while on Android Auto while I’m driving around town. Maybe 1 song in 10 (or maybe once per 45 minutes) exhibits this issue.
I did have an experience where Plexamp would transcode and play a flac file and Symfonium would not (it skipped the song entirely). The file was non-standard, but I don’t know how or why. Windows would show blanks in certain metadata fields for the file, and conversion software like “flac frontend” would error & fail to convert it. I had to take some special measures to re-encode the file, and once I did, Symfonium would play it (and Windows would show the proper metadata, etc.
Question: Does Symfonium transcode & download the entire file at once? Or does it do it in chunks or batches? Does Symfonium transcode & download the entirety of the next file in the queue while the current one is playing? I ask these questions because while I’m driving around, my cellular connection will change unavoidably.
I’d like to revisit this. What settings can I try to get more reliable playback of transcoded files while moving into and out of cellular signal (i.e., while driving, or when leaving home wifi / returning to home wifi)?
Just now, I took a walk. Playback continued fine for a few minutes when returning home, and then just paused (a circle was spinning around the play button in the UI) near the end of one song at about 13:50:00 local time. Symfonium them restarted the song from the beginning. This is typical of the kind of behavior I experience when I’m in my car, but can’t often catch because I’m driving at the time.
EDIT: In Plexamp and in other players, I recall settings that allow me to cache the next several songs. I’d expect Symfonium has something like that. And, I’d expect that kind of caching to buffer against the occasional move from one internet signal to another.
EDIT 2: I don’t fully understand the difference between the “playback” cache and the “rolling” cache. I had 8gb for the former, and “disabled” for the latter. I changed them to 4gb and 8gb respectively, but I still don’t understand what’s goign on. Plexamp, for example, has only one cache setting.
EDIT 3: It may not be a cache issue. Or, it’s not transcoding & caching the next “X” songs while playing the current one. I say this because, despite the changed cache settings, Symfonium hung at the end of another song while out on another walk (~15 minutes into the walk, at the end of the 7th song in the queue). The UI displayed a spinning circle around the Play icon, and clicking on it did nothing. I had to manually force it to the next song, though once I did it played without issue for the rest of the walk.
Rolling cache is about the actual file cache for offline playback.
The playback cache is the option you need, with the pre cache songs values you want.
In the logs again the server returns error 400 sometimes, so the pre cache can’t work and so if there’s network issues during playback restart can happen if you are transcoding Symfonium can’t resume on retries.
My apologies. I can’t help mixing-up things I don’t fully understand.
First, I don’t understand the need for / function of the two caches. If I’m receiving (“streaming”? “downloading”?) a transcoded file and listening to it, and if I want to let that transcoded copy be available for offline/local playback in the future–as long as the cache isn’t full and new stuff isn’t overwriting the old stuff–that sounds like storing it in a “rolling” cache. But, based on your above answer, that’s not correct. Is the software holding a received transcode in the (temporary?) “playback” cache before it copies it to the “rolling” cache?
The above is somewhat irrelevant, though. Based on my experience with Plexamp–where there’s an option to cache the next # of songs–I would expect any cache to fill up with completed transcodes of the next # of songs as fast as it can. I’d then expect those to play from the cache, effectively buffering through any temporary network issue. Rinse & repeat. Given my settings and average song durations, I should have 5-15 minutes to let Symfonium cache the next (i.e., #+1) transcoded song in the list. Based on my experience, that doesn’t seem to be happening.
There’s docs that explains all, so yes there’s the playback cache that store what you play and pre cache items, for playback purpose it’s store in blocks and can contains just part of the media.
Then there’s the offline cache rolling or not to really cache the media for actual full offline playback with an option to copy from the playback cache to it when it’s possible.
Now about the rest.
Again this is how it works and it works correctly except when your server returns error 400 so cancel the pre cache …
In fact most of your songs in the last logs are already cached. (Logs that contains things since April BTW)
