No compatible streams are currently available (PPC)

[alucryd 214]

Thanks for the report, we'll see how we can disable the image processors in the next beta.

[ppggff 1]

Any news about the ppc version?

I tried the 4.8.0.21 version:

• start successfully
• ffmpeg, ffprobe coredump due to "Illegal instruction"
• high cpu usage(190%) when accessing the home page from web

and the 4.7.11.0 version:

• start failed, mono crashed with SIGSEGV

I can help with testing with my ds413. Thanks for the great job.

[alucryd 214]

@ppggffWill have to get back to the drawing board, the fact that it still fails with illegal instruction proves that I still need to tweak the toolchain. Could be that CPU doesn't fully adhere to its supposed specs, and the GCC target cpu overshoots some stuff. I'll see if I can't target something lower, but my PPC knowledge only goes so far.

[Luke 36999]

On 1/8/2023 at 9:39 PM, ppggff said:

Any news about the ppc version?

I tried the 4.8.0.21 version:

• start successfully
• ffmpeg, ffprobe coredump due to "Illegal instruction"
• high cpu usage(190%) when accessing the home page from web

and the 4.7.11.0 version:

• start failed, mono crashed with SIGSEGV

I can help with testing with my ds413. Thanks for the great job.

@ppggff can you please attach the emby server log from the beta? Thanks.

[alucryd 214]

@Luke I have one last thing I want to try, I'm already targeting a generic powerpc architecture, which should run across all CPUs, but it's very possible one of the libs is enforcing altivec hardware acceleration despite that (which the qoriq lineup doesn't have), resulting in some illegal instructions being called. I'll try explicitely forcing it off in my build flags, hopefully that will make the compiler crash if a lib is indeed misbehaving, or at least I hope to see a warning in the build logs. I'll go over all builds once again to see if I get a glimpse of something.

[alucryd 214]

Well, turns out GCC will happily accept conflicting flags without so much as a warning, and just use the last one, meaning that even if I specify `-mno-altivec`, any lib is free to override that, and some do. Going over build logs, I found at least 2, x264 and x265 that were activating altivec behind my back, I hope they were our culprits. There might be more, but these are the ones where it was at least visible in some way either in the configure or build log.
@ppggffCan you give this build a try? https://www.dropbox.com/s/f3s2lwjgzcng9bk/emby-server-synology-mono_4.8.0.21_ppc.spk?dl=0

[ppggff 1]

On 22/01/2023 at 23:32, alucryd said:

Well, turns out GCC will happily accept conflicting flags without so much as a warning, and just use the last one, meaning that even if I specify `-mno-altivec`, any lib is free to override that, and some do. Going over build logs, I found at least 2, x264 and x265 that were activating altivec behind my back, I hope they were our culprits. There might be more, but these are the ones where it was at least visible in some way either in the configure or build log.
@ppggffCan you give this build a try? https://www.dropbox.com/s/f3s2lwjgzcng9bk/emby-server-synology-mono_4.8.0.21_ppc.spk?dl=0

Thanks a lot, I will test it as soon as I got back home from my parents' house this weekend.

[ppggff 1]

I installed the package from https://www.dropbox.com/s/f3s2lwjgzcng9bk/emby-server-synology-mono_4.8.0.21_ppc.spk?dl=0

• start successfully
• ffmpeg, ffprobe still coredump due to "Illegal instruction"
• ffdetect works

server log is attached.

embyserver-63810547200.txt

Edited January 28, 2023 by ppggff

[alucryd 214]

Thanks for the feedback. Digging a little deeper, I can see that altivec is indeed gone from x264 and x265, but it seems nettle still has some altivec refs despite me telling it to disable it... Also openssl might be to blame, although looking at openssl's code it seems optional and checked at runtime so it should in theory be fine. Still I'll try some stuff and get back to you. Will also include strace in the next package, that might tell us more. 

[alucryd 214]

@ppggffHere's a new package: https://www.dropbox.com/s/oa9jrvh3mijvgbd/emby-server-synology-mono_4.8.0.21_ppc.spk?dl=0

Forced more stuff, but I'm not very hopeful. I included strace, if you know how to get your hands dirty.

You should find a script on the NAS at `/var/packages/EmbyServer/target/bin/emby-ffmpeg`.

If you change the line:

exec bin/ffmpeg "$@"

to:

exec bin/strace -s 512 -o /tmp/strace -f bin/ffmpeg "$@"

It should print a bunch of useful stuff in `/tmp/strace`, you just need to run the script with the same arguments from a failed ffmpeg invocation you can find in your logs.

With all that said, I have a new plan which should allow me to get rid of the offensive library, just need to consult our ffmpeg expert first.

[ppggff 1]

@alucryd Last package gives the same result: coredump due to "Illegal instruction"

server log and strace results are attached.

"strace_xxx" means "emby-ffmpeg" with different argument.

embyserver.txt strace_version strace_protocols strace_hwaccels strace_filters strace_encodes strace_decoders

[alucryd 214]

Thanks! Looks like it fails almost immediately, right after loading libdl, that's rough. In the meantime I got rid of gnutls in favor of mbedtls, but these straces make me think there really is sth wrong with the toolchain, it shouldn't fail that early. Let me try sth, will get back to you with a new package later today.

Edited January 29, 2023 by alucryd

[alucryd 214]

@ppggffSorry about the delay, ran into some trouble building a new toolchain. Here's a new package: https://www.dropbox.com/s/vi66a73enaw4rn3/emby-server-synology-mono_4.8.0.21_ppc.spk?dl=0

I call it schroedinger's package, it may fix everything, or just break things even further, we will see.

[ppggff 1]

@alucryd Last package failed to start, and ffmpeg still coredump with Illegal instruction.

server log and strace results are attached. (For ffmpeg, I tried two arguments.)

embyserver.txt strace_verbose strace_decoders

[alucryd 214]

@ppggffThanks, it doesn't make sense, I'm using the most generic PowerPC target and even switched to soft float instead of hard float, it should increase compatibility, not decrease it I have one last idea, but we're starting to stray a bit far from what I'd like, I'll build a toolchain targeting this CPU specifically, the downside is I will probably break other PPC packages, although I don't think they're even used anymore, Synology is the last one afaict.

[alucryd 214]

@ppggff New package, I built a toolchain specifically for the e500v2 cpu family, with SPE extensions, this targets exactly what's inside the DS413. It looks like GCC killed support for SPE a while ago, so I'm limited to GCC 8 (compared to 10 for all other platforms) but I was still able to build everything with it. Might also explain why it's been a pain until now if GCC 10 doesn't officially support this kind of PowerPC CPU anymore, fingers crossed.

https://www.dropbox.com/s/1k568nc1lf7q17o/emby-server-synology-mono_4.8.0.21_ppc.spk?dl=0

Edited February 3, 2023 by alucryd

[ppggff 1]

With the last package, good news: ffmpeg works, bad news: server start failed.

•  from /var/log/messages: coredump: Process Emby[Main] dumped core on signal [Threa].

I tried the package from Github, server start success.

server log and coredump attached.

embyserver.txt @Emby.core.gz

[alucryd 214]

Thanks, we're getting there. I don't know what to do with that coredump, and the server log doesn't show anything useful. I assume there is a mono error afterwards, but you'll need to run emby manually from a terminal to see it as it won't show up in the server log. Could you try that and report back? Might need a couple runtime flags to get going, armv5 was fixed that way on Synology. With a proper error I can also take it to the mono devs so they can help figure it out.

Using the official toolchain from Synology is not an option as it's way too old to build half the stuff we need, so we need to get this more recent one to work.

[ppggff 1]

Attached log is what happened when running emby-server directly. 

Notes:

• The first time it was executed, it coredumped immediately
• Then I remove the server log, it coredumped after many startup messages

run.log

[trex13 0]

Just got same NAS DS213+ and was very happy when I saw that there is NAS PPC version of Emby server, but after unsuccessful install of both versions (stable and beta) I discovered this thread which confirmed me it never worked on this hardware.

Just wanted to ask is there any hope for making this work on this hardware?

[Luke 36999]

3 hours ago, trex13 said:

Just got same NAS DS213+ and was very happy when I saw that there is NAS PPC version of Emby server, but after unsuccessful install of both versions (stable and beta) I discovered this thread which confirmed me it never worked on this hardware.

Just wanted to ask is there any hope for making this work on this hardware?

Hi, yes, we would still like to get this figured out. Can you please attach an emby server log from the beta?

How to Report a Problem

Thanks.

[trex13 0]

On 5/2/2023 at 8:00 PM, Luke said:

Hi, yes, we would still like to get this figured out. Can you please attach an emby server log from the beta?

How to Report a Problem

Thanks.

Hi,

I'm not sure which one is it, so I'm attaching both + hardware_detection log if you need it.

embyserver.txt embyserver-63819159222.txt hardware_detection-63819159282.txt

[trex13 0]

Any news on this topic?

[alucryd 214]

I've had no answer yet unfortunately

https://github.com/mono/mono/issues/21658

[Sparker 31]

I had this error on Synology NAS (DSM 7.2), and to fix it I had to ensure emby had read/write permissions on the media shared folder (mine is called data), and restart the Emby Server.

I migrated from DS720+ to DS923+ this weekend and I can tell you it has not been fun, those folder permissions were setup, but somehow got deleted along with Plex with the hundred other things I was doing restoring my NAS environment because ofc it was only partial with the migration wizard. I lost all my Docker containers...