Jump to content
Sock

Transcoding issue on Raspberry PI

Recommended Posts

Sock

Thanks for looking into it

 

FYI, on the permissions, I can see the /var/lib/emby/transcoding-temp folder has the following permissions (755) which look fine for emby.

 

drwxr-xr-x  2 emby emby 159744 Aug 21 17:06 transcoding-temp

 

On that basis, it seems like it's most likely it's the first suggestion, where the initial file write handle doesn't get closed properly (or similar)?

Share this post


Link to post
Share on other sites
softworkz

Thanks for looking into it

 

FYI, on the permissions, I can see the /var/lib/emby/transcoding-temp folder has the following permissions (755) which look fine for emby.

 

drwxr-xr-x  2 emby emby 159744 Aug 21 17:06 transcoding-temp

 

On that basis, it seems like it's most likely it's the first suggestion, where the initial file write handle doesn't get closed properly (or similar)?

 

You must not look at the folder, you need to look at the permissions of the created .m3u files.

Share this post


Link to post
Share on other sites
Sock

Ah, ok. I've just checked again and all the files (.m3u8 and .ts) have 644 permissions:

 

-rw-r--r--  1 emby emby    160 Aug 29 01:25 c78429b4b27f4c0f2c59ee11dbb9ac55.m3u8

 

I tried updating the permissions to 755 or 777, but the file was almost immediately rewritten to 644.

 

Hope that helps!

 

Thanks

Share this post


Link to post
Share on other sites
softworkz

@@Sock - OK, then it is a permissions issue because after you changed it to 755, it could be written (once).

 

The next thing to check is under which user account ffmpeg is running.

 

But whatever the result - I'm out at this point.

 

@@Luke or @@alucryd will know what to do from here.

Share this post


Link to post
Share on other sites
Luke

@@Sock has this helped?

Share this post


Link to post
Share on other sites
Sock

I'm afraid not @@Luke - nothing has been fixed that I'm aware of. 

 

To add a little more detail on top of previous - running top shows that ffmpeg is running under the emby account, which looks correct to me.

 

I'm not sure I completely buy permissions being the issue - the .m3u8 file is owned by the emby user, which has rw permissions - so emby/ffmpeg should be able to write to this file without issues.

 

Also, the m3u8 is replaced periodically, as in deleted and recreated. If the process can do that, it should be able to modify the file too (from a permissions point of view)

 

Thanks again for your help

Share this post


Link to post
Share on other sites
Luke

Have you tried the latest beta server with the newer ffmpeg?

Share this post


Link to post
Share on other sites
softworkz

I'm afraid not @@Luke - nothing has been fixed that I'm aware of. 

 

To add a little more detail on top of previous - running top shows that ffmpeg is running under the emby account, which looks correct to me.

 

I'm not sure I completely buy permissions being the issue - the .m3u8 file is owned by the emby user, which has rw permissions - so emby/ffmpeg should be able to write to this file without issues.

 

Also, the m3u8 is replaced periodically, as in deleted and recreated. If the process can do that, it should be able to modify the file too (from a permissions point of view)

 

Thanks again for your help

 

Besides permissions it could also be an issue of concurrent file access, but permissions is the most likely cause and that must be the first step to investigate: We need to find out whether it's a permissions issue or not.

 

To do this, we need to configure the OS in a way that files in that folder are created with full permissions (777).

 

As mentioned before I'm no Linux expert, but I remember that there is a way to set the default permissions for files created in a certain folder. 

This is not necessarily just the containing folder's permissions. You can try that first and if it doesn't help, look up the other way I referring to.

 

I'm afraid that I can't offer more detailed steps here, I can only provide the strategy for pinpointing the problem.

 

Hopefully somebody else could chime in and help with the details.

Share this post


Link to post
Share on other sites
Sock

Have you tried the latest beta server with the newer ffmpeg?

 

Sorry @@Luke, I haven't had a chance to look yet. I will give it a try ASAP. 

 

As mentioned before I'm no Linux expert, but I remember that there is a way to set the default permissions for files created in a certain folder. 

 
I'm no Linux expert either, but I think you're referring to unmask, so I'll look into that. As I said previously though, I think that permissions may be a red herring, as everything is running under the `emby` user (which has full permissions to that directory already)

Share this post


Link to post
Share on other sites
softworkz

 

Have you tried the latest beta server with the newer ffmpeg?

 

Sorry @@Luke, I haven't had a chance to look yet. I will give it a try ASAP. 

 

As mentioned before I'm no Linux expert, but I remember that there is a way to set the default permissions for files created in a certain folder. 

 
I'm no Linux expert either, but I think you're referring to unmask, so I'll look into that. As I said previously though, I think that permissions may be a red herring, as everything is running under the `emby` user (which has full permissions to that directory already)

 

 

You might be right, that it's not a permissions issue.

But you might also be wrong.

 

To pinpoint the problem we need to go step by step, starting from the most likely to the less likely things.

 

Your log files showed that ffmpeg always stopped when trying to write to a file for the second time, so it must be related to disk I/O.

Share this post


Link to post
Share on other sites
softworkz

Thanks for the results.

 

We could test it in another way:

 

While transcoding is running, and you're at - let's say 45 min: Delete the first 500 files in the transcoding folder.

 

Then, see whether transcoding still stops at about 1h.

Edited by softworkz

Share this post


Link to post
Share on other sites
Sock

Ah ok, this is something I've already tested in a way!

 

The issue with transcoding doesn't only when transcoding has been running for 1h. It also occurs if the media starts stuttering, I stop it, (+ optionally restart the server/clear temporary files) and then resume. 

 

When I resume and it's ~1hr in, you get exactly the same stuttering. And the number of files at that point can be very low (in the 10s for example) so shouldn't be hitting that limit

Share this post


Link to post
Share on other sites
softworkz

The issue with transcoding doesn't only when transcoding has been running for 1h. It also occurs if the media starts stuttering, I stop it, (+ optionally restart the server/clear temporary files) and then resume. 

 

When I resume and it's ~1hr in, you get exactly the same stuttering. And the number of files at that point can be very low (in the 10s for example) so shouldn't be hitting that limit

 

Even after restarting the OS?

Share this post


Link to post
Share on other sites
Sock

Even after restarting the OS?

 

Correct!

Share this post


Link to post
Share on other sites
softworkz

And in the stuttering case you're always seeing lots of ffmpeg logs generated while it's just a single (long) ffmpeg log when it's working?

Share this post


Link to post
Share on other sites
softworkz

Those ffmpeg processes are always crashing returning error code 139 (which means SEGFAULT).

Unfortunately I got no idea why.

Share this post


Link to post
Share on other sites
Sock

And in the stuttering case you're always seeing lots of ffmpeg logs generated while it's just a single (long) ffmpeg log when it's working?

 

Yes, exactly.

 

 

Those ffmpeg processes are always crashing returning error code 139 (which means SEGFAULT).

Unfortunately I got no idea why.

 

Sounds like installing the beta with the newer ffmpeg version is the best bet then.

Share this post


Link to post
Share on other sites
Luke

Let us know how things go. Thanks.

Share this post


Link to post
Share on other sites
softworkz

Unfortunately I'm running out of ideas. The current installation doesn't allow testing ffmpeg commands from the command line, and we don't have any diagnostic options in the server yet, which would allow to try some more things. I hope we will have better ways for diagnosing problems in the future.

Share this post


Link to post
Share on other sites
Sock

Doh, ah well. Thanks for investigating - I appreciate the effort!

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...