1311 – permanent rescan and hang issue

  • Post date

FireFly Media Server › Firefly Media Server Forums › Firefly Media Server › Nightlies Feedback › 1311 – permanent rescan and hang issue

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • 25/07/2006 at 7:10 AM #463
    schiers
    Participant

    Hi Ron,

    after a while of perfectly running nightlies, I have a question which might
    not be related to the used 1311. It could also be a communication
    problem between Firefly and Roku. Please let me describe the issues
    before I further debug.

    I started to use noflushd and hdparm to switch off the disks of my server
    that are not dedicated to the os, means e.g. the RAID-1 array for music.

    1. hang issue

    Assume the discs are down. When I now swiitch on the Soundbridge, it will
    be able to browse. Selecting a song results in a waiting time (correct, the
    discs need to spin on), but then it says it’s unable to play. I guess a
    timeout has fired. Do you know which timeout? Firefly or Roku? Couldn’t
    we handle this somehow, by sending silence or whatever?

    2. rescan

    I noticed that when I switched off the Soundbridge during playback of a
    song that Firefly continues to rescan, althouh no client should be present.
    I noticed that the connection I switched off is stll mentioned on the
    status page.

    I have restarted Firefly now. It stopped scanning. Shall I analyse on this?
    Isn’t there a kind of timeout to shut down a client that shows no activity?

    Best Regards,
    Carsten.

    P.S.: Shall I crosspost to Roku Forum, or are they reading here, too?

    25/07/2006 at 1:05 PM #5632
    rpedde
    Participant

    @schiers wrote:

    1. hang issue

    Assume the discs are down. When I now swiitch on the Soundbridge, it will
    be able to browse. Selecting a song results in a waiting time (correct, the
    discs need to spin on), but then it says it’s unable to play. I guess a
    timeout has fired. Do you know which timeout? Firefly or Roku? Couldn’t
    we handle this somehow, by sending silence or whatever?

    Maybe, but there are other times where that doesn’t work. If the db is on the spun-down drive (like I have) then it causes problems just connecting, and that can’t be solved on the server side.

    2. rescan

    I noticed that when I switched off the Soundbridge during playback of a
    song that Firefly continues to rescan, althouh no client should be present.
    I noticed that the connection I switched off is stll mentioned on the
    status page.

    Was that through daap or rsp, and was it transcoded or not transcoded? I’d like to follow up on that.

    Isn’t there a kind of timeout to shut down a client that shows no activity? If the client socket is shut down, then it should return immediately. That’s breakage on my side.

    P.S.: Shall I crosspost to Roku Forum, or are they reading here, too?

    The timeout issue might be reasonable to report over there. I’ll point someone over at this thread, though, so they can take a look at the whole thing. Thanks.

    — Ron

    25/07/2006 at 2:50 PM #5633
    schiers
    Participant

    Hi Ron,

    Maybe, but there are other times where that doesn’t work. If the db is on the spun-down drive (like I have) then it causes problems just connecting, and that can’t be solved on the server side.

    I double checked but the db is on a ever running disc. That’s the reason why I can browse immediately. But when it comes to serving, the access to the mp3 will take its extra 3-5 seconds. Here the Soundbridge is too fast giving up.

    I was hoping the protocol will go like this:

    1. Soundbridge->Server: gimme that thing
    2. Server->Soundbridge: just wait a bit, it’s coming
    3. wait
    4. Server->streaming

    If this isn’t working, I guess the timeout of the Soundbridge is slightly too short.

    Was that through daap or rsp, and was it transcoded or not transcoded? I’d like to follow up on that.

    It was rsp, serving an ordinary mp3 file. I will check whether this is can be reproduced and report back.

    CU Carsten.

    25/07/2006 at 2:56 PM #5634
    rpedde
    Participant

    @schiers wrote:

    I double checked but the db is on a ever running disc. That’s the reason why I can browse immediately. But when it comes to serving, the access to the mp3 will take its extra 3-5 seconds. Here the Soundbridge is too fast giving up.

    Right. What I’m saying though, is that I regularly get bitten by the “connecting to server”… hang… hang… hang… sb crash, because MY db is on the spun-down drive.

    So my vote would be to crank up the timeouts on the sb side, as that will fix both of our problems. 🙂

    25/07/2006 at 7:30 PM #5635
    schiers
    Participant

    OK, some more news. I checked again. Indeed it is reproducable. I mean both. But I don’t think it can be solved by a longer timeout. Let me describe exactly:

    1. drive down
    2. switch on SB
    3. browse (takes some time)
    4. select track
    5. it takes roughly 10 seconds for SB top respond it doesn’t wok
    6. play next wil work
    7. switch off
    8. last served song will resist and keeps Firefly to rescan
    9. the problems are connected. If it doesn’t hang, it will not stay

    I tried to reproduce it with -d9 or so, but then it worked. It then also worked without -d something, so I guess it needs to be sent to sleep for a longer time. Let me try tonight and we see in some hours. I love those bugs that appear only from time to time…

    BR,
    Carsten.

    25/07/2006 at 8:37 PM #5636
    schiers
    Participant

    Hi Ron,

    I was able to reproduce it when I waited the system to go to bed during I watched a very interesting feature on the US in the 50s (Peyton Place and the man in grey flannel etc.).

    I send you the log zipped to ron at pedde dot com.

    I have set the whitelist to let you answer 😆

    BR,
    Carsten.

  • Author
    Posts
Viewing 6 posts - 1 through 6 (of 6 total)
  • The forum ‘Nightlies Feedback’ is closed to new topics and replies.