MediaBrowser / Emby

Emby Server is a personal media server with apps on just about every device.
https://emby.media
GNU General Public License v2.0
4.15k stars 806 forks source link

Added support for WD My Cloud #3298

Closed stefaang closed 6 years ago

stefaang commented 6 years ago

I added support for WD My Cloud NAS but it's not so easy to unpack the .deb files. Now I need to get entware tar to be able to unpack an LZMA compressed archive. See here

If simpler tarball releases would be available both for x64 and ARM, I could drop the entware requirement for installation. The install directory for this platform is /shares/Volume_1/Nas_Prog/emby.

Any suggestions?

LukePulverenti commented 6 years ago

I didn't know there were x64 WD's? I thought they were all armel. It's been a while since I've looked at them all. I assume by arm you mean armel?

stefaang commented 6 years ago

The DLxxxx and PRxxxx line is x64, the rest is armhf afaik. More info here

They've also recently launched the My Cloud Home, a new product line with android M... looks like a good candidate for https://emby.media/community/index.php?/topic/53944-emby-server-for-android/ ... Yes, a headless device running android. I may be interested to create a port similar to https://github.com/stefaang/wd-cuberite or https://github.com/stefaang/wd-nzbget It would come down to this:

alucryd commented 6 years ago

While the arm CPUs from Marvell are indeed armhf capable, the WD firmware is armel and won't run armhf code. Did you try running your package on any of the arm models?

stefaang commented 6 years ago

No I don't have an arm model, but the EX models have docker and they are able to run armhf images according to here and here.

alucryd commented 6 years ago

Docker images ship their own implementation of the C stdlib (glibc, musl, uclibc or whatever the case may be) and dynamic linker, which is why they can (in theory, because the linux kernel does not use hardware floating point, but not always true) run armhf code even if the host is armel, provided the CPU does have a VFP unit. Our deb packages don't ship the C stlib and use the system one instead, everything inside uses the armhf dynamic linker (ld-linux-armhf.so.3) while the WD firmware has the armel dynamic linker (ld-linux.so.3).

stefaang commented 6 years ago

Thanks for the detailed explanation. Would it be possible to get around this limitation by adding ld-linux-armhf.so.3 to the WD binary package and load it with LD_LIBRARY_PATH?

alucryd commented 6 years ago

Possibly, but that's where the in theory comes in, I already tried on my EX2 Ultra to no avail, the dotnet runtime refused to work even with the right dynamic linker. I should give docker another try though, it's way easier to do the testing with it.

alucryd commented 6 years ago

Now that I know there are x64 models, I tried adding wd packages to our builds, but I don't have any x64 wd device at hand. Would you be willing to give them a try?

LukePulverenti commented 6 years ago

You can participate in testing here: https://emby.media/community/index.php?/topic/59597-emby-server-for-western-digital-nas/

Thanks guys.

LukePulverenti commented 6 years ago

Closing. This will be up on the website soon. Thanks everyone.