Jump to content
Sock

Transcoding issue on Raspberry PI

Recommended Posts

Sock

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!

Share this post


Link to post
Share on other sites
Sock
Luke

Hi @@Sock, are you able to test other input besides avi files and see how that compares? Thanks.

Share this post


Link to post
Share on other sites
Sock

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

Share this post


Link to post
Share on other sites
Luke

Do you have any mkv's to try with? Thanks.

Share this post


Link to post
Share on other sites
Luke

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

Share this post


Link to post
Share on other sites
Sock

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

Share this post


Link to post
Share on other sites
Luke

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

Share this post


Link to post
Share on other sites
Sock

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

Share this post


Link to post
Share on other sites
Luke

Ok yes that would be helpful. Thanks.

Share this post


Link to post
Share on other sites
Sock

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

Share this post


Link to post
Share on other sites
Luke

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.

Share this post


Link to post
Share on other sites
Sock

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

Share this post


Link to post
Share on other sites
Luke

Can you try an mkv, given that avi's always tend to be tricky? Thanks.

Share this post


Link to post
Share on other sites
Luke

Ok yes please do, thanks.

Share this post


Link to post
Share on other sites
Luke

Have you tried playing them in the web app? How does that compare?

Share this post


Link to post
Share on other sites
Sock

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

Share this post


Link to post
Share on other sites
Sock

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

Share this post


Link to post
Share on other sites
Luke

@@softworkz will take a look at this. Thanks.

Share this post


Link to post
Share on other sites
Sock

Brilliant, thanks. Appreciate it.

Share this post


Link to post
Share on other sites
softworkz

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.

Share this post


Link to post
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...