Emby unusable for transcoding with latest FFMPEG?

[Guest]

This might be linux specific i'm not fully sure right now.

 

I attached a log of me attempting to play something.

 

Edit:

 

Attempting to run the exact ffmpeg command provided by the doc poses the following error:

Invalid loglevel "timing". Possible levels are numbers or:
"quiet"
"panic"
"fatal"
"error"
"warning"
"info"
"verbose"
"debug"
"trace"

Removing the -loglevel argument, poses the following error:

Unrecognized option 'print_graphs_file'.

 

 

log.txt

Edited June 10, 2020 by PRAGMA

[Luke 42079]

Hi, please attach the complete emby server log. We don't use your system ffmpeg. We bundle our own version.

[Guest]

Attached. P.S. The logs do state /bin/ffmpeg

embyserver.txt

Edited June 10, 2020 by PRAGMA

[Luke 42079]

How did you install emby server?

[Luke 42079]

I think this is your underlying issue:

	file:/mnt/emby-1/tv/The Amazing World of Gumball/The.Amazing.World.of.Gumball.S01.1080p.AMZN.WEB-DL.AAC2.0.DD+2.0.x264-Vadimsrzn/The.Amazing.World.of.Gumball.S01E01-02.The.Responsible.The.DVD.1080p.AMZN.WEB-DL.AAC2.0.DD+2.0.x264-Vadimsrzn.mp4: No such file or directory

If you can resolve that then you'll probably be good to go. That looks like either the mount is not accessible or the server is not being granted permission to open the file.

[Guest]

How did you install emby server?

The issue started out of seemingly nowhere. I did very recently update my system ffmpeg, are we sure it's using a bundled ffmpeg?

It was installed with sudo pacman -S emby-server from Arch Linux community repo (which is now removed? check my other post in arch linux pinned thread).

I didnt do a thing to emby since, no change to emby occured between the issue, in fact I was on a slightly outdated version of emby, I have since removed it and installed it with docker and set /config to /var/lib/emby (essentially retaining all config from pacman install).

[Guest]

I think this is your underlying issue:

	file:/mnt/emby-1/tv/The Amazing World of Gumball/The.Amazing.World.of.Gumball.S01.1080p.AMZN.WEB-DL.AAC2.0.DD+2.0.x264-Vadimsrzn/The.Amazing.World.of.Gumball.S01E01-02.The.Responsible.The.DVD.1080p.AMZN.WEB-DL.AAC2.0.DD+2.0.x264-Vadimsrzn.mp4: No such file or directory

If you can resolve that then you'll probably be good to go. That looks like either the mount is not accessible or the server is not being granted permission to open the file.

This file does exist, and I should mention, this error is happening on basically every file I can try attempt

[Guest]

I attached an ffmpeg-transcode specific log, might help?

ffmpeg-transcode-ff07d3b3-288e-4507-b537-496e12eb7e3a_1.txt

[Luke 42079]

The repository we're looking into, but the file error, i can only tell you what i am seeing:

03:57:15.100 /mnt/emby-1/tv/Family Guy/Family.Guy.S16.1080p.AMZN.WEB-DL.DDP5.1.H.264-CtrlHD/Family.Guy.S16E08.Crimes.and.Megs.Demeanor.1080p.AMZN.WEB-DL.DDP5.1.H.264-CtrlHD.mkv: No such file or directory

[Guest]

Even when attempting to play on my android TV which can "Direct Play" this file as stated in dashboard, is stuck on a black screen that loops a "Too many errors, giving up" message.
I can tell you the file and path does exist and emby itself can discover it when attempting to navigate to it in library

[Luke 42079]

I believe you that it exists, but it looks like there is an issue preventing emby from opening the files for reading. Usually that points to permissions.

[Guest]

I believe you that it exists, but it looks like there is an issue preventing emby from opening the files for reading. Usually that points to permissions.

I even went ahead and removed the entire tv library, re-added, and re-added the paths. On the docker, they didnt show up, but using `downgrade` to go back to my pacman install and then removing and re-adding paths, they showed up, and once it scanned a few episodes in, I tried playing and the same thing happens, so clearly its finding and being able to read the files.

[Guest]

I will say, in the episode details, scrolling all the way down to Media Info, all it can say is the container and path, so maybe its not being able to read it?

[Guest]

New error, some problem with ffprobe? Seems the path this time isn't /bin/ffprobe, but /usr/bin/ffprobe-emby, meaning the other instances was in fact using the system bin?

 

 

embyserver.txt

[Guest]

This bug report on ffmpeg makes it clear they forgot to update the bin references for libaom to v2: https://bugs.archlinux.org/task/66796

Doing `downgrade aom` back before v2.0.0 fixes that ffprobe issue, but the main issue still stands.

[Guest]

Ok awesome, after doing that, doing a server reboot worked like a charm. I guess the 404 stuff was just a docker issue (I've no experience in using docker, probably did something wrong).

 

Hopefully the liboam fix for ffmpeg goes through soon.

[Luke 42079]

Great, thanks for the feedback.

[Guest]

I should note however, while it did fix the emby instance, it did break Firefox's internal video decoder (it probably was referencing libaom v2.0.0), but ffmpeg was updated, as well as liboam and since the arch linux repo put emby-server back up, I also updated emby-server and now it's working like a charm.

[sekondchakra 6]

I was having multiple playback issues (arch linux) around the time of this thread, and downgrading aom "fixed" the issue.  There was a bug filed on aom 2.0, so I was waiting for it to be addressed, but yesterday the developer cleared it saying that he wasn't able to reproduce the issue.

ffmpeg has been updated 3 or so times since early June, but I still get playback errors with aom 2.0 (and downgrading to 1.0 still "fixes" them).  As the aom package maintainer isn't having an issue--could this be emby-related?   (I've since upgraded emby-server-beta also.)  I'll attach logs.

Running emby-server-beta 4.5.0.14.  ffmpeg v4.3.1.

Full disclosure:  Some files play back without errors, but most do not.

Thoughts?  

embyserver_playback.errors.txt ffmpeg-transcode-49dec6df-2b03-4563-9cb4-c9f46563678f_1.txt

Edited July 22, 2020 by sekondchakra

[Guest]

7 hours ago, sekondchakra said:

I was having multiple playback issues (arch linux) around the time of this thread, and downgrading aom "fixed" the issue.  There was a bug filed on aom 2.0, so I was waiting for it to be addressed, but yesterday the developer cleared it saying that he wasn't able to reproduce the issue.

ffmpeg has been updated 3 or so times since early June, but I still get playback errors with aom 2.0 (and downgrading to 1.0 still "fixes" them).  As the aom package maintainer isn't having an issue--could this be emby-related?   (I've since upgraded emby-server-beta also.)  I'll attach logs.

Running emby-server-beta 4.5.0.14.  ffmpeg v4.3.1.

Full disclosure:  Some files play back without errors, but most do not.

Thoughts?  

embyserver_playback.errors.txt 448.61 kB · 0 downloads ffmpeg-transcode-49dec6df-2b03-4563-9cb4-c9f46563678f_1.txt 6.94 kB · 0 downloads

Hi, so, an update for me at least is that I no longer have pacman forcing aom to stay on 1.x, its now on the latest version for quite some time now without issues. I have had the rare occasion where a specific file wouldnt play however I do not remember what ones they were. I can however confirm the following play back fine for me at least the majority: DVD Remuxes (both NTSC and PAL), BluRay Remuxes, General AVC, General H.265.

I don't know exactly why its working for me again. For AOM I used the pacman pkg "aom" and for ffmpeg I used the pkg "ffmpeg", both official repo.

I have only very recently moved my Emby server to docker too, perhaps you should try it? It's been making everything more much convenient for me :)

If you do go the Docker route, I recommend installing Portainer and using the official emby-server docker image which is: https://hub.docker.com/r/emby/embyserver

To get you going on docker really easily, do the following:

1. Install Docker on your system
2. Install Portainer via docker-run (dont bother with docker-compose for this its unnecessary for now)
3. Go to Volumes tab and create a new volume, I recommend just calling it emby-server-data, something verbose for what its for, which is going to be used for /config for emby-server.
4. Go to Containers tab and create a new container, name it emby-server (something verbose as usual), for "Image configuration" select "DockerHub" and in the input field type "emby/embyserver" for the official emby image.
5. Keep everything default for now including ports and what not and just scroll down and click the Volumes button/tab, click "map additional volumes". For "container" field put "/config" and for "volume" click it and select the volume you made earlier (emby-server-data). Make sure the mode is "Volume", "Writable".
6. Now, map another volume and this time choose the mode "Bind", and choose read only if you want. This is where you map the files you want emby to be able to find, assumingly from your HDD mount paths. What I do is just use the same path on my host for container, so e.g. on my system I have /mnt/emby-1 as one of my hdd's, so I just use that for both fields "container" and "host", that means emby-server will see that mounted hdd at the same path as on my actual system, makes debugging paths on debug logs much easier. Go ahead and add all the paths you want emby-server to see now, as it's not the easiest to add new ones later without having to shut it down and re-create it.
7. Click the network button, make sure its "bridge" mode we dont want to use the others at least not right now, and go ahead and in the hostname field put something verbose as usual, e.g. emby-server, this hostname is visible on your network so it makes it easy to debug what exactly the network device is.
8. Click the restart policy button and choose one you wish, personally I use "Always" as I ALWAYS want it running, but another good option is "Unless Stopped".
9. Do nothing else and just click "Deploy Container". Once deployed look for it in the container list and it will have a "(i)" circle blue i info icon, click it and look for "NetworkSettings" and click that. Inside that look for "Ports" and click it. It should list a couple ports, they should say "port_num/port_type", make note of it by screenshotting or copy/paste.
10. Back out to container list and click emby-server and top right click "Duplicate/Edit" and go ahead and under "Network ports configuration" make sure "Publish all exposed network ports to random host ports" is disabled, and click "publish a new network port" for however many ports you took note of earlier. It will show "Host -> Container" fields, "Container" is the port that the container will be signaling, and "host" is the port that will be used on your actual machine for you to be able to visit. The ports you took note of earlier are the ports Emby-server is signaling, so jot each one down into the container field (right side) making sure you click the right port type (udp/tcp) for each one, its important it matches. Then on the host (left side) you can either use the same port, or a different port if the port emby-server uses is already in use (btw make sure not to make a mistake here of having pacman emby-server running, which will be using these ports most likely, so if you want the same ports that docker emby uses internally, `systemctl stop emby-server` while doing this step). Once you configured the ports, go ahead and deploy container again.
11. You should be good to go, you should now have it running on the "host" (left side) ports you specified, some ports may not work via a browser or some devices which is why theres multiple, just keep trying them until one works in your device (e.g. localhost:8096 is what I use). To migrate your server data from pacman instance, you need to stop your docker emby, fire up the pacman one, and go to it in your browser, go install the server backup plugin from within emby dashboard, and use that to make a backup (emby will need write permissions for wherever you wish to "store" the backups, I had awful trouble for some reason and only /var/lib/emby worked to place the backups, which is where emby stores the general server configs). Once you set up the plugin, click "Scheduled Tasks" tab in dashboard and there should be a "Run Backup" task with a play button, click that to run a backup now, copy that backup to one of the mount points you told the docker emby to have access to, and you need to simply install the server backup plugin again on the docker version and set the backup point to where you stored the pacman backup, it should appear "Restore backup" with the file name showed, click that and your up and going exactly where you left off other than needing to rescan your library.

[sekondchakra 6]

Thanks for the elaborate tutorial!   I don't know that I'd ever heard of docker, and I'm curious what the advantages of going this route would be.   Without knowing any more about it, isn't this another layer of complexity?  

And, I too am running the pacman aom & ffmpeg.  But I have to freeze aom at the 1.0 version, too many errors with the 2.0...

[Guest]

5 hours ago, sekondchakra said:

Thanks for the elaborate tutorial!   I don't know that I'd ever heard of docker, and I'm curious what the advantages of going this route would be.   Without knowing any more about it, isn't this another layer of complexity?  

And, I too am running the pacman aom & ffmpeg.  But I have to freeze aom at the 1.0 version, too many errors with the 2.0...

Docker is technically another layer of complexity but it makes the long term use of stuff like emby way more enjoyable.

For example, to update Emby with docker, you would just click "Duplicate/Edit" and straight away "Deploy Container" and it will update the image while retaining all settings, paths, volumes, mount points, settings, network configuration e.t.c.

It's like having another linux sub-system just for Emby, with it being completely blocked from your main system files, even / as it has its own!

Its good for security too in case a bad actor comes along that tries to wipe your HDD's or something, since you can set it as read-only preventing that. You can permission it however you want down to the last detail which I love. With portainer you can even see details about it like CPU/MEM/IO usage for JUST emby-server called stuff, super handy.

Since it's an entire sub-system, with its own linux image, it literally deals with all the pre-dependencies on its own, so aom/ffmpeg e.t.c is handled by itself and not related to pacman's aom/ffmpeg, it's basically a solution to the "it works on my machine" phrase as its literally an image of emby-server working on one specific machine, then duplicated onto other systems via docker.

[sekondchakra 6]

On 7/22/2020 at 7:48 PM, PRAGMA said:

Docker is technically another layer of complexity but it makes the long term use of stuff like emby way more enjoyable.

Well, I think you've made a convert out of me.  The setup (and learning curve) took 8 to 10 hours (my connectivity problems were solved by changing the network mode from "bridge" to "host")--but I like how now my mission-critical emby setup is (hopefully) no longer subject to package mis-matches, etc, like I've had more than once in the past.  Thanks for the suggestion and all of the off-forum help!