Jump to content

Transcoding issue on Raspberry PI


Sock

Recommended Posts

Hi, I've recently set up a RaspberryPi as an Emby Server. Overall, it works surprisingly well! Convinced me to stump for Emby premier :)

 

Unfortunately there's one specific issue I'm seeing when the client can't stream directly (I'm using a Fire TV and Chromecast).

 

Initially, transcoding works fine - the movie plays without any issues. But about 30mins - 1 hour in, the film starts stuttering - it'll play ~10 seconds, then jump back 2, play another 10 and jump back... Makes it un watchable unfortunately :( 

 

My initial thoughts were that it was just due to the Pi being underpowered, but that doesn't explain why it works fine for ~1 hr!

 

I've attached the server and transcode logs for the most recent incident.

 

Any help greatly appreciated!

Link to comment
Share on other sites

Hi Luke, I see the same behaviour whenever transcoding is required (e.g. h264 Level is too high). I'll try and find an example to grab the logs

Link to comment
Share on other sites

Do you have any with the h264 codec, as opposed to mpeg4. These are all divx, right?

Link to comment
Share on other sites

Hi @@Luke, sorry, missed your reply.

 

There's a bit of a hodge-podge of codecs as I changed over the years. Yes, the older stuff is largely divx/xvid and avi, and newer stuff is h264.

 

To be clear, you want me to find an h264, mkv file where transcoding is required, right? I'll find one and grab the logs

Link to comment
Share on other sites

That would be very helpful, thanks. You could also try the beta server as it has a newer ffmpeg build.

Link to comment
Share on other sites

Hi @@Luke, I have an h264 MKV here that was transcode due to level to high (51). Same behaviour. Logs attached

 

It appears to happen every time conversion is required. It plays fine while the transcoding is ongoing, but seems to get confused once the transcode has finished and keeps restarting transcodes. 

 

RE the beta server - I'm using dietpi and not entirely sure how to go about that. I'd rather stick to the stable releases if possible, but if it'll help I'll give it a go. 

embyserver_1122.txt

ffmpeg-transcode_0851.txt

ffmpeg-transcode_0925.txt

ffmpeg-transcode_0926 (1).txt

ffmpeg-transcode_0926 (2).txt

ffmpeg-transcode_0926 (3).txt

Link to comment
Share on other sites

  • 1 month later...

Hi @@Luke,

 

Apologies, I've been away so I didn't get round to this. Back now and I noticed a new version of Emby server so I tried updating, but I still see exactly the same behaviour unfortunately Anything else I can try? I can send the latest logs again if that's of any use...

 

Thanks!

Andrew

Link to comment
Share on other sites

Hi @@Luke,

 

Apologies, I've been away so I didn't get round to this. Back now and I noticed a new version of Emby server so I tried updating, but I still see exactly the same behaviour unfortunately Anything else I can try? I can send the latest logs again if that's of any use...

 

Thanks!

Andrew

 

@@Sock can you please describe what you're still seeing? thanks.

Link to comment
Share on other sites

Sure, approximately an hour into watching something that is being transcoded, you start seeing glitches every ~5 seconds, with it jumping back ~1s. Watching the server dashboard, you can see the media switch repeatedly between transcoding and direct play. It's as though emby keeps forgetting it's already finished transcoding, and starts again. Every time it stutters it creates another ffmpeg-transcode log (I've attached a couple of the latest)

ffmpeg-transcode-f40b6578-4c6d-47de-847a-793d0f331d81_1.txt

ffmpeg-transcode-4f9285c1-fefc-4482-950f-5c8d89ef45e3_1.txt

Link to comment
Share on other sites

Interesting. In the web apps (Chrome on Windows + Chrome on Android) I saw a couple of initial stutters (extra on Android), but afterwards it played back fine. I still the same behaviour in emby server though, with separate transcode logs being generated multiple times a second

embyserver.txt

ffmpeg-transcode-1d42f5db-d950-4dc2-8ccc-c30aed305776_1.txt

ffmpeg-transcode-2c2b2f2d-6af2-437f-8ca0-005dd04be5bd_1.txt

ffmpeg-transcode-38ba0f0c-6ef0-45b2-9b1c-4e61323ac214_1.txt

Link to comment
Share on other sites

Hi @@Luke, sorry to bother you again, I just wondered if you had any other ideas about this issue? I'm loosing the Wife Acceptance Factor battle at the moment

Link to comment
Share on other sites

  • 2 weeks later...

We don't have the same amount of experience on the RPI as we have on other platforms.

 

But I think I can narrow it down pretty closely.

 

What is common to almost all of the ffmpeg logs that you've posted is that it appears to be crashing at a very specific point which is always the same.

And that is the moment when it attempts to overwrite the m3u playlist file it had just created seconds before.

 

It's always the identical pattern:

  • ffmpeg creates and writes the m3u playlist
  • it writes the first segment
  • it tries to re-open the m3u playlist for writing (to update)
    => Crash

 

From a quick brainstorming, there's only causes I can imagine:

  • There's some kind of problem with the file API platform libraries, in a way like that the initial file write handle doesn't get closed properly 
    (or similar)
    .
  • A permissions issue, like: The account under which ffmpeg is executed has incorrect permissions for the transcoding-temp folder
    (/var/lib/emby/transcoding-temp)
    This could be like that the executing account is allowed to create and write new files but is not allowed to modify existing file (even self-created ones)

 

I'm not an expert for that platform, but I think this will help to find the actual cause.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...