Jump to content

Transcoding issue on Raspberry PI


Recommended Posts

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)?

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.

Link to post
Share on other sites

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

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.

Link to post
Share on other sites

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

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.

Link to post
Share on other sites
  • 2 weeks later...

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)
Link to post
Share on other sites

 

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.

Link to post
Share on other sites

I got a new theory: It could also be an issue about too many open files. I'm basing this on the assumption that your RPI OS image might have a lower limit configured than other Linux distros.

 

You can read here https://serverfault.com/questions/610130/how-to-set-ulimit-value-permanently - how to increase the limit (for testing - not as a solution)

Link to post
Share on other sites

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
Link to post
Share on other sites

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

Link to post
Share on other sites

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?

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

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