Sock 0 Posted August 25, 2019 Author Share Posted August 25, 2019 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 comment Share on other sites More sharing options...
softworkz 3335 Posted August 25, 2019 Share Posted August 25, 2019 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 comment Share on other sites More sharing options...
Sock 0 Posted August 29, 2019 Author Share Posted August 29, 2019 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 comment Share on other sites More sharing options...
softworkz 3335 Posted August 29, 2019 Share Posted August 29, 2019 @@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 comment Share on other sites More sharing options...
Luke 37064 Posted September 2, 2019 Share Posted September 2, 2019 @@Sock has this helped? Link to comment Share on other sites More sharing options...
Sock 0 Posted September 7, 2019 Author Share Posted September 7, 2019 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 comment Share on other sites More sharing options...
Luke 37064 Posted September 7, 2019 Share Posted September 7, 2019 Have you tried the latest beta server with the newer ffmpeg? Link to comment Share on other sites More sharing options...
softworkz 3335 Posted September 7, 2019 Share Posted September 7, 2019 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 comment Share on other sites More sharing options...
Luke 37064 Posted September 18, 2019 Share Posted September 18, 2019 @@Sock has this helped? Link to comment Share on other sites More sharing options...
Sock 0 Posted September 18, 2019 Author Share Posted September 18, 2019 > 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 comment Share on other sites More sharing options...
softworkz 3335 Posted September 18, 2019 Share Posted September 18, 2019 > 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 comment Share on other sites More sharing options...
Sock 0 Posted September 18, 2019 Author Share Posted September 18, 2019 Link to comment Share on other sites More sharing options...
softworkz 3335 Posted September 21, 2019 Share Posted September 21, 2019 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 comment Share on other sites More sharing options...
Sock 0 Posted September 21, 2019 Author Share Posted September 21, 2019 Link to comment Share on other sites More sharing options...
softworkz 3335 Posted September 21, 2019 Share Posted September 21, 2019 (edited) 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 September 21, 2019 by softworkz Link to comment Share on other sites More sharing options...
Sock 0 Posted September 21, 2019 Author Share Posted September 21, 2019 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 comment Share on other sites More sharing options...
softworkz 3335 Posted September 21, 2019 Share Posted September 21, 2019 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 comment Share on other sites More sharing options...
Sock 0 Posted September 21, 2019 Author Share Posted September 21, 2019 Even after restarting the OS? Correct! Link to comment Share on other sites More sharing options...
softworkz 3335 Posted September 21, 2019 Share Posted September 21, 2019 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? Link to comment Share on other sites More sharing options...
softworkz 3335 Posted September 21, 2019 Share Posted September 21, 2019 Those ffmpeg processes are always crashing returning error code 139 (which means SEGFAULT). Unfortunately I got no idea why. Link to comment Share on other sites More sharing options...
Sock 0 Posted September 22, 2019 Author Share Posted September 22, 2019 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 comment Share on other sites More sharing options...
Luke 37064 Posted September 22, 2019 Share Posted September 22, 2019 Let us know how things go. Thanks. Link to comment Share on other sites More sharing options...
Sock 0 Posted September 23, 2019 Author Share Posted September 23, 2019 @@softworkz I just upgraded to the Beta server (4.3.0.9) but still seeing the same behaviour I'm afraid I've uploaded a sample of the logs in case that's useful, but looks like the same as before to me. embyserver.txt ffmpeg-transcode_2123_1.txt ffmpeg-transcode_2123_2.txt ffmpeg-transcode_2123_3.txt Link to comment Share on other sites More sharing options...
softworkz 3335 Posted September 24, 2019 Share Posted September 24, 2019 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 comment Share on other sites More sharing options...
Sock 0 Posted September 24, 2019 Author Share Posted September 24, 2019 Doh, ah well. Thanks for investigating - I appreciate the effort! Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now