SlimServer On DiskStation -- Release 2b1

[flipflip]

Hallo

I uploaded a new release of SSODS.

http://oinkzwurgl.org/software/ssods/

Now with support for SlimServer 6.5.0.

Until now, there only exists a version for the powerpc variants of the diskststions (101g+, 106*, 406). I'm still working on the arm version.

Have fun.

Regards,
flip

[hkfriends]

Woow... thanks a lot

btw, why no more share on \\DiskStation\SlimServer

[tommypeters]

Thanks, I have tried to follow your ddiscussion in German with Mr Hyde...

Is this new SSODS also compatible with 6.3.1?
Edit: Found out att SSODS web place that it indeed does. Thought I should maybe not change everything at once...

[flipflip]

Yeah, the sqlite-stuff is included, so 6.2.x and 6.3.x will work (I tested 6.3.1).

What do you mean by "no more share \\DiskStation\SlimServer"? You can still create (or rather activate) that share via the DS web interface.

I didn't test it, but that should work as before since the SlimServer files are still in /volume1/SlimServer.

If you do not see the directory in the DS admin interface, do a reboot. It looks like the DS checks for the folders in /volume1/ only once on boot.

[hkfriends]

Yeah, the sqlite-stuff is included, so 6.2.x and 6.3.x will work (I tested 6.3.1).

What do you mean by "no more share \\DiskStation\SlimServer"? You can still create (or rather activate) that share via the DS web interface.

I didn't test it, but that should work as before since the SlimServer files are still in /volume1/SlimServer.

If you do not see the directory in the DS admin interface, do a reboot. It looks like the DS checks for the folders in /volume1/ only once on boot.

Thanks, after re-boot, it works.

[bpa]

Now that you have mplayer working - mplayer can be used to support m4a (AAC) and AACplus streams as well with a few more entries in the types and convert conf files.

[mr_hyde]

Now that you have mplayer working - mplayer can be used to support m4a (AAC) and AACplus streams as well with a few more entries in the types and convert conf files.

Hello bpa,

flip has modified the mplayer with respect to stream to stdout. Now it is possible to stream to wav which results only in a 6.5% CPU usage. There is no need for mkfifo. That's great.

I have also tested your generi plugin. It works.

mr_hyde

[bpa]

I saw the changes to mplayer - it should be noted somewhere in a README that it is a modified mplayer.

mplayer developers have been asked to make mplayer process stdout properly and not use it for messages.

They have been converting mplayer modules to use mpmsg but there may be still some which output messages to stdout.

I did a bit more researching and I now think you could have been able to use the /proc entry - but that is academic now.

[flipflip]

I saw the changes to mplayer - it should be noted somewhere in a README that it is a modified mplayer.

It is (README.ssods/README.txt). And I renamed the binary to "mplayer-stdout".

They have been converting mplayer modules to use mpmsg but there may be still some which output messages to stdout.

They have and that's where I changed the code (mp_msg.c). Now everything goes to stderr instead of stdout (s/stdout/stderr/g).

And I changed libao2/ao_pcm.c to trap the magic filename "-". That will bypass the fopen() and fclose() calls and assing stdout to the file descriptor.

As the changes are trivial and the result is more an ugly hack than a decent patch, I chose to not report it upstream.

The "patch" is of course available: http://www2.ggl.ethz.ch/flip/ssods/m...patches.tar.gz

flip

[bpa]

I understand your code changes and they are good.

What I meant by output from modules - output from codecs or demuxers such as debug messages or when invalid datastreams are found. Some modules are careless thinking stdout is available because decoded data normally goes to video and audio card.

It is possible that if you use mplayer for another codec or demux protocol you will get a corrupted datastream. I don't think it is anything to worry about just be aware if you try something new.