- This topic has 8 replies, 7 voices, and was last updated 18 years, 4 months ago by
.
-
Posts
-
Ron,
The functionality of the Firefly server is great – all the features I need.
Unfortunately for me, it still stops working on my Slugs after around 1.5 hrs (30-40 tunes).
Does anyone else experience this problem on an NSLU2 ?
This is very frustrating as I’d like to use Firefly ! 🙁I’ve tried all releases since 1005 and had the same result.
I have 2 slugs – one is de-underclocked and the other is standard
I consistently get the same result on both. If I start a client playing through a big playlist and let it run, Firefly just stops serving tunes after about 1.5 hrs.
Sometimes it stops in mid tune, sometimes on new track.
Client sees messages like “Opening URL …” or “Network stalled … rebuffering stream”.
At that point, “PS” on the slug shows only 2 threads for mt-daapd and it no longer responds to requests for music. However the web app function “Stop Server” still functions and will stop the connection to the server.This morning I played a few seconds from many tracks in a playlist. Then I left it to run through the rest of the playlist automatically. Under these conditions it served 86 tracks and stopped after 1.25hrs.
Both slugs are “Unslung V2.3R63-uNSLUng-6.8-beta”
Configuration of the 2 slugs is slightly different
SlugA- Standard, unslung to USB HDD, mp3 dir: /share/flash/data/public/iTunes Music
SlugB- Deunderclocked, unlsung to 2Gb USB stick, mp3 dir:
/share/hdd/data/HDD_1_1_1/public/iTunes Music/
Both music directories contain the same 9,500 tune library.
All tracks are either mp3 or AAC.
I’ve run SlugA in debug level 8, but the log just ended at the song title being served when the music stopped. I gave up with debug level 9 after the log hit 30Mb.I’d welcome any suggestions for how to diagnose this problem.
PS: I have been running the last stable release of mt-daapd on Xebian (Debian on Xbox) for months and it is rock solid. It serves 4-6 iItunes clients pretty much continuously, and it just works 😀
Hi richo132,
I have the same problem but I’m not sure if this is a basic firefly problem. My slugs show similar symtoms when initiating heavy I/O load like cp -R /dir1 /dir2. I experience this behavior since the first versions of UNLSUNG.
The work around for me for firefly was to deactivate the directory ‘Rescan Interval’. Now the slug doesn’t freeze during playback and I start scaning manually 🙁 – but it works.
Maybe someone else can explain these slug-experience?I had this problem too, but after sending Ron a few logs he tracked down the problem and released 1303, which seems to work OK for me now.
I’m running uNSLUng 5.5 though.
Is there any downside to running uNSLUng 5.5 ?
Is anyone having success with V2.3R63-uNSLUng-6.8-beta and Firefly ?
Cheers.Hi guys,
You know what ? I’ve got the same problems sometime my slug freeze and i need to reboot it removing power supply.
I’m not a specialist but I think the slug is out of ressources in these cases but I don’t know how to track it to verify that point
I’ve got unslung 6.8 with mt-daapd only. Using samba to backup my server diskimage file each night. that’s all why I user my slug (@266Mhz)
Is there any downside to running uNSLUng 5.5
I personally think it is a better firmware than 6.8.
However do remember that there is no support for NTFS drives however.
All of mine are natively formatted ext3 on the slugs.I have 2 slugs, my main one running mt-daapd 024 (unslung 5.5) and another test one (unslung 6.8.) I do have an experimental firefly (1157 I think ) installed, and it seems to be stable enough.
Both the slugs are de-underclocked, but I do feel that the unslung 5.5 version is just slightly quicker. I noticed during the unslinging of 6.8 that the unslung 6.8 firmware uses about 97% of the flash mem compared to about 83% in 5.5.
I am waiting for the first stable release of firefly before I ungrade my unslung v5.5 slug. After which I will probably reflash my 6.8 down to 5.5 as well.
Pete
After playing with other projects for a while I have revisited this issue.
At first I had trouble getting my Slug to run Firefly at all –
mt-daapd.log had hundreds of “Error statting: No such file or directory”
I believe this was because the iTunes XML file was out of synch with the MP3 dir. So, for now, I’ve renamed the XML file.
In the process of sorting that out, I noticed that I had a songs.gdb file hanging around so I removed that as well.
After a reboot, the Slug has been running faultlessly for over 5hrs now…
Does this give any indication of the root cause ?@richo132 wrote:
After playing with other projects for a while I have revisited this issue.
At first I had trouble getting my Slug to run Firefly at all –
mt-daapd.log had hundreds of “Error statting: No such file or directory”
I believe this was because the iTunes XML file was out of synch with the MP3 dir.yup, that’s almost certainly it.
So, for now, I’ve renamed the XML file.
In the process of sorting that out, I noticed that I had a songs.gdb file hanging around so I removed that as well.
After a reboot, the Slug has been running faultlessly for over 5hrs now…
Does this give any indication of the root cause ?Dunno, but there have been a bunch of performance issues fixed since 1311. Mine is noticably snappier, and reindexes faster than it has in a long time.
Might just be related to that. I’d be interested to hear if you have any continued problems.
My slug has been running for 2 days, having served 70 songs. Prior to upgrading to latest nightlies (for testing, really, not because it was broken) I had almost 700 songs served, and it had been up several weeks.
So it’s definitely getting more stable… at least with *my* usage patterns.
- The forum ‘Nightlies Feedback’ is closed to new topics and replies.