Paging with WLAN?

[coffee]

Hi All

I installed a wireless HDD (WLAN) for my music and videos. My problem is that even with the music config file it takes very long to page through the music on freebox (much longer than normal). Videos also takes up to 5 second to start playing but otherwise the video and audio files plays well. The 5 second before the video starts playing is not a problem for me it's only the paging through the music that's a problem to me.
My JPG-files sizes is 320 max. Will it help to make them even smaller? Have somebody a suggestion for me?

Coffee           

[spudgunman]

well there are SO many reasons this is a issue and FJB isnt to blame for 80% of them that are the downfall of using such technology

however if things go well with new DB backend this will solve some of the issues.

[kizer]

So are you storing all of your music on a server and using a another machine to access the files? I did the same thing a while back via wireless and it did take a bit longer, but seemed to do better via a wired connection.

[coffee]

Yes, it's much better with a wired connection but it's allways a hassle to update a juke on site and it takes to much time so I though something like this could come in handy. Won't know if you don't try it.

[Barcrest]

You really do need it to be wired. I used an N wireless adapter and that was ok but still not great. Wireless isn't as good as they say it is.   

[coffee]

Hi Barry

I agree, it really is not that good.       

[netcat]

I was going to say the same 802.11 N would be the fastest way. in my experience over a wire the trasnsfer of large files takes longer than the equivalent MBs in small files.

lots of issues come into play such as the efficiency of transfer protocols within TCP/IP and what not.

long story short YES, if you make smaller files they obviously would arrive to the destination faster (as there is less to move) but wireless may not be the best approach.

I am currently using an external 500Gb in a USB enclosure.

I must admit I do still have a wireless connection to the jukebox in order to update the software and do library transfers to it, I also use it from my laptop on ocassion to take remote control (www.radmin.com) and lower volumes, change tracks etc.

Which reminds me. I would still really really really like to get some remote control functionality within the jukebox. (hint hint)

[kizer]

Im the same way. I use 2 drives. 1) 160gig, 1) 250gig for storage. One of them is my primary jukebox database and the other is a backup. I use this app to keep them up to date because its free for one and I have no issues just clicking on a button to launch the sync and man it scans fast as !@#$ http://www.karenware.com/powertools/ptreplicator.asp

I plan on installing a new drive in my server, which is a p350 hahaha, but making it my primary source for the few PC's in my house and then dump my music on it and have my other PC's run that above app so they are all the same.

[spudgunman]

I was going to say the same 802.11 N would be the fastest way. in my experience over a wire the trasnsfer of large files takes longer than the equivalent MBs in small files.

lots of issues come into play such as the efficiency of transfer protocols within TCP/IP and what not.

long story short YES, if you make smaller files they obviously would arrive to the destination faster (as there is less to move) but wireless may not be the best approach.

I am currently using an external 500Gb in a USB enclosure.

I must admit I do still have a wireless connection to the jukebox in order to update the software and do library transfers to it, I also use it from my laptop on ocassion to take remote control (www.radmin.com) and lower volumes, change tracks etc.

Which reminds me. I would still really really really like to get some remote control functionality within the jukebox. (hint hint)

actually the major problem here is that FJB currently works like this...

Read the DB
Open the file
Read the tag
Read the JPG
Play the file


all of this is done with API calls for local drives.

So you get a delay on each read while the drivers for the remote disk go via the transmission stack. So each time you have a lookup you have this delay

Also each lookup via API is using "on box SMB" which then must traverse the wireless

SMB is bloated and UGLY

so add to the delay.

--- not to hack up your post but actually you get better thruput on larger files due to the OSI layer explanation. The smaller files is the killer

also not to mention that WMP and streaming via a local file isnt like streaming off the web, there is no caching to buffer so there is constant file calls to the disk (i think you can change this)

---


So in the future frosty and I hope to help B. get the backend on a DB so that the file calls are no so often, and to address other posts, you could have the media on a seprate drive then the database file so that local database calls are local disk and only file call for the media are remote, thus speeding this up  10 fold.

However a "Remote disk" via wireless is not acceptable for any disk use application so all of this shouldnt be a huge issue for people wanting to get performance


---


as far as a "Remote" see my post in the other thread, I use a remote that works well. OR you can do a number of things like use VNC or just send remote keyboard calls to the windows API from another computer.