Ffprobe Error

[Thuzad 42]

@softworkz is it by any chance the same for ffprobe? 

When I scan my library remotely, I get this error:

2022-05-23 12:05:37.357 Info MediaProbeManager: ProcessRun 'ffprobe' Execute: /opt/emby-server/bin/ffprobe -i file:"/media/storage9/series/Doom Patrol/Season 2/Doom Patrol - S02E01 - Fun Size Patrol - WEBDL-1080p - h264 EAC3[EN+FR] [FR].mkv" -threads 0 -v info -print_format json -show_streams -show_chapters -show_format -show_data
2022-05-23 12:05:37.756 Info MediaProbeManager: ProcessRun 'ffprobe' Process exited with code 127 - Failed
2022-05-23 12:05:37.757 Error App: Error in ffprobe
        *** Error Report ***
        Version: 4.7.0.60
        Command line: /opt/emby-server/system/EmbyServer.dll -programdata /var/lib/emby -ffdetect /opt/emby-server/bin/ffdetect -ffmpeg /opt/emby-server/bin/ffmpeg -ffprobe /opt/emby-server/bin/ffprobe -restartexitcode 3 -updatepackage emby-server-deb_{version}_amd64.deb
        Operating system: Linux version 5.10.0-12-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1
        Framework: .NET 6.0.2
        OS/Process: x64/x64
        Runtime: opt/emby-server/system/System.Private.CoreLib.dll
        Processor count: 4
        Data path: /var/lib/emby
        Application path: /opt/emby-server/system
        System.Exception: System.Exception: Error running ffprobe for file:"/media/storage9/series/Doom Patrol/Season 2/Doom Patrol - S02E01 - Fun Size Patrol - WEBDL-1080p - h264 EAC3[EN+FR] [FR].mkv" - /opt/emby-server/bin/ffprobe: error while loading shared libraries: libavdevice.so.59: cannot open shared object file: No such file or directory


           at Emby.Server.MediaEncoding.Probing.MediaProbeManager.GetMediaInfoInternal(String inputPath, String primaryPath, MediaProtocol protocol, String userAgent, Boolean extractChapters, String probeSizeArgument, Boolean isAudio, Boolean forceEnableLogging, CancellationToken cancellationToken)
           at Emby.Providers.MediaInfo.FFProbeVideoInfo.ProbeVideo[T](MetadataResult`1 metadataResult, MetadataRefreshOptions options, LibraryOptions libraryOptions, CancellationToken cancellationToken)
           at Emby.Providers.Manager.MetadataService`2.RunCustomProvider(ICustomMetadataProvider`1 provider, MetadataResult`1 itemResult, String logName, MetadataRefreshOptions options, LibraryOptions libraryOptions, RefreshResult refreshResult, CancellationToken cancellationToken)
        Source: Emby.Server.MediaEncoding
        TargetSite: Void MoveNext()

 

[Luke 37274]

Hi there @Thuzad please attach the complete emby server log. Thanks.

[Thuzad 42]

Attention this is in a very particular context I use rffmpeg, that's why I had published in the previous topic.

I succeeded to solve my problem by taking the ffprobe binary directly on the site of ffmpeg.

I only wanted to know if you were going to add an emby-ffprobe like for emby-ffmpeg, nothing more. But if you really want I can provide you with the logs, but I don't think you should spend time on it.

Thank you.

[Luke 37274]

Ok thanks for the info.

[Thuzad 42]

Do you have an answer for this question?

I only wanted to know if you were going to add an emby-ffprobe like for emby-ffmpeg

@softworkz

[softworkz 3350]

4 hours ago, Thuzad said:

Do you have an answer for this question?

I only wanted to know if you were going to add an emby-ffprobe like for emby-ffmpeg

@softworkz

No, we aren't going to add an emby-ffprobe...

...but you can do that quite easily

• Make a copy of emby-ffmpeg
• Name it emby-ffprobe
• Edit the file in a text editor and replace ffmpeg with ffprobe
• Make sure the file has execute permissions
• Go!

[Thuzad 42]

Thanks a lot for the tip ! I didn't know it was only a text file 

Edited May 24, 2022 by Thuzad

[softworkz 3350]

Please note that when you do any remote execution experiments with ffmpeg/ffprobe, you'd also need to run ffdetect remotely to make sure it detects what's available on the remote system (where ffmpeg is run) instead of the local one.

Edited May 24, 2022 by softworkz

[Thuzad 42]

Yes thank you also for this information that I discovered just before posting this topic. The whole remote system seems to be working fine as well as ffdetect.

I used the modifications of this fork:

https://github.com/ddscentral/rffmpeg/commit/6231adb9cfccaa7c1eca1d73fc1cd1500eafb485

[softworkz 3350]

May I ask about your motivation for remote execution?

I mean, just that part wouldn't be hard to implement in Emby, but I think the whole story would only have a benefit when you could have MULTIPLE remote servers to do transcoding for once, but also serving the transcoded segments directly - and all that...would be really a big thing to do.

[Thuzad 42]

Of course, this is primarily a personal challenge. Putting this together and understanding how the author of this script did it is a real asset to know a bit about how Emby works.

Then it's mostly to offload my main server which is an i5 and runs a lot of personal services that use a lot of CPU. Having no graphics card and a small CPU, the transcoding is quickly limited. 

Then all my data/media are on this server (i5) and so I use the power of my transcoding server (an i7) to give it all the work. The i7 does not store any data. Another reason is that this server is much better cooled than my i5 and the remote transcoding allows to reduce the temperature a bit. 

Obviously an Emby supported solution would be much better. But it would be better to create a highly available cluster where you can cut an Emby node without any problem. But I know that this is not easy to set up. 

[softworkz 3350]

12 minutes ago, Thuzad said:

Obviously an Emby supported solution would be much better. But it would be better to create a highly available cluster where you can cut an Emby node without any problem. But I know that this is not easy to set up. 

It's quite a challenge to develop this because there's a lot of interaction required to coordinate the operation of multiple "transcoding slaves". The whole thing doesn't make sense when all the playback data would still go through the primary server while all control still needs to be handled by it. So it will need a lot of communication between those servers and that would be a whole new development. Also, many structures and data would need to be extended to track all operations, log files will need to be collected and aggregated, path management will be important as all paths will need to be able to be re-mapped, etc etc.. - that's still just the tip of the iceberg.

There's a lot of cost involved for this and we cannot let the regular Emby users pay for something which is of interest for a few only. The only way this could fly would be in the context of a a commercial project.

[Thuzad 42]

I completely agree with all your arguments and I also think that such a system would only be useful for a commercial aspect. And I think that's not what the basic users want to go towards. 

What could be interesting is to have only the possibility to transcode remotely and on several servers (like rffmpeg does). Of course we wouldn't be looking for high availability anymore, but rather for load balancing. Even if I think that this aspect would not interest many people, I find it rather interesting. 

Another possibility would be to create a cluster a bit like Patroni does (high availability system for PostgreSQL). It uses a leader/replica/replica logic. But even for this method you need a minimum of 3 nodes. And this is only for the database which is only one piece. This means a complex infrastructure, commercial and not for everyone. 

Finally I think that the only interesting feature in the cluster stories for Emby is really the possibility to transcode remotely without having high availability. 

[softworkz 3350]

4 minutes ago, Thuzad said:

Finally I think that the only interesting feature in the cluster stories for Emby is really the possibility to transcode remotely without having high availability. 

This is actually implemented already (for a different upcoming feature). The execution engine which runs all the external processes can do remote execution via SSH just as if it was local. Maybe we can expose that in the future (as an unsupported option or something), but I can't promise right now...

[Thuzad 42]

Wow! Unbelievable! I hope to be able to test it in the near future. 
Thanks again for your feedback and the work.