Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Tolga]

I don't use library server. Instead, the files are stored at a shared network location that can be accessed from all computers, and I copy the "master" library to other computers from time to time. This is a nightmare if multiple people want to keep playlists. I have solutions for that, but none of them are good solutions.

The major reason why I don't use the server is that it is slow. To speed it up
both the library and the thumbnails should be cached on the client side. Getting the library takes a constant time, each time you open MC on client side. Why not just check that the library has not been motified, and use the local version? Also, if the cover art is large, it takes a lot of time to transfer them. why not create the thumbnails on the server side, and transfer them to the client only if they are changed?

I wonder whether these issues are considered in the new server under development.

[John Gateley]

Hi Tolga,

Both are good ideas, and we are thinking about these and other ways to make the server faster. I'm not sure how it will turn out, we'll see.

j

[paulr]

This is my primary concern about it.  The way it works right now, it will be impossible to use a dial-up modem on the client due to the library download size, and the cover art..  

Even with many DSL connections, like mine (15KB/s upload), it will take over 3 minutes for my server to upload the library (12+ minutes if the client is on dial-up).  Additional time will be required for cover art - a lot of my cover art is 300+ KB.

To make this more usable, I think the caching idea is good.  Ideally, the server would only upload the library once, and only upload changes after that.  The option to turn off cover art uploads is also needed.

[JimH]

You can set up a second library with fewer files imported, and share that.

Though 3 minutes to fire up over a modem isn't bad.  Windows takes about 10 minutes to boot.

[paulr]

Oops, John posted while I was typing!

I'm glad you guys are looking in to ways to make this better!  Looking forward to it.

[John Gateley]

it will be impossible to use a dial-up modem on the client due to the library download size, and the cover art..  

This is not an issue, because a dial-up modem is too slow to listen to streaming music.

j

[paulr]

Windows takes about 10 minutes to boot.

My computer boots Windows XP Pro in about 1 minute.  Anyway, the three minute figure was for DSL upload.  It's more like 12+ minutes for a 56K modem (not including cover art).

This is not an issue, because a dial-up modem is too slow to listen to streaming music.

Sorry, but that's not accurate.  Quality isn't good, for sure, but you can certainly stream at low bitrates.  In addition, cover art will take even more time.  At 15KB/s, a 300KB cover art file will take 20 seconds to upload (1 minute if the client is on dial-up).

I think the option (in the client) to not request cover art is a good idea.  With a 15KB/s upload limit, I'd rather not saturate my upload stream with cover art when it isn't needed.

An example of software that does this streaming with few issues (except it doesn't yet support APE) is SlimServer.  It uses a web interface to select and control song playback (similar to Remote Server), and will allow a person to use just about any client that supports streaming to listen.

Anyway...  I take these responses to mean that you are not intending to support low bitrate client connections.  =/

[Tolga]

Hi Tolga,

Both are good ideas, and we are thinking about these and other ways to make the server faster. I'm not sure how it will turn out, we'll see.

j

Thanks. As I always do, I will check the forum zillion times/day for updates  . I admit, I am an update addict.

[John Gateley]

Sorry, but that's not accurate.  Quality isn't good, for sure, but you can certainly stream at low bitrates.  In addition, cover art will take even more time.  At 15KB/s, a 300KB cover art file will take 20 seconds to upload (1 minute if the client is on dial-up).

Anyway...  I take these responses to mean that you are not intending to support low bitrate client connections.  =/

Your DSL line is 15KBytes/second which is 120KBits/second, or more than twice as fast as a 56K modem.
The fastest I acheived on a modem was around 38KBits/second, or somewhere around 32Kbits maximum
bitrate for a song.

There has been no demand previously for modem support. I still like the caching ideas, and will work on those in the future.

j

[paulr]

Your DSL line is 15KBytes/second which is 120KBits/second, or more than twice as fast as a 56K modem.
The fastest I acheived on a modem was around 38KBits/second, or somewhere around 32Kbits maximum
bitrate for a song.

True.  But, if a friend of mine wanted to check out a song or a new artist, he would still be able to stream using MP3 32 or 40kbps.  Since he would be using MC to receive the stream, he might be inclined to purchase it....

Anyway, I am glad you are looking at a caching option.  I would suggest you also look at the option to disable cover art on the client, because even if the client was on a high bitrate connection, it would still take some time for a server on aDSL to upload the images (my DSL line is actually 128kbs up, but I rarely actually achieve it).

Thanks for the good work!

[Dragyn]

both the library and the thumbnails should be cached on the client side

as this is a good idea, MC should use the thumbnails already created. takes way too long to view a page of images because it has to download the whole file, then create the thumbnail.

other reason I don't use it is because it can't stream apl files.