Announcement

Collapse
No announcement yet.

Plex Server and AudioCast

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Plex Server and AudioCast

    I'm using a Plex Server as my DMS, HS3 Mediacontroller as my DMC and a AudioCast as the DMR. The Plex Server is on a different PC from HS3. The Mediacontroller on HS3 sees the AudioCast and I can setup a playlist and stream to the AudioCast, but after 1 or two songs or tracks, the AudioCast disconnects from HS3 Mediacontroller. Some times it will disconnect while the song is playing and will play to the end and stop. Anyone else trying anything like this. I plan on using the AudioCast or something like it as one of the sources for my nuvo house sound system. AudioCast says it's DLNA but who really knows. I've checked the network and don't thing it is the problem (drop outs). I've now tried three different Audio cast devices -Pyle, AudioCast and YunListen. All have the same outcome.

    Attached is a error log where it disconnects:
    Pyle_disconnect.txt
    Last edited by jccook200; April 29, 2018, 09:27 AM.

    #2
    Hi,
    I have a similar circumstance. I also use the Audiocast as the DMR, but it will only respond to the plugin if the plugin has been stopped and restarted, or if the Audiocast has been powered off and on. Otherwise, it says "Activated - offline" and it won't respond to the plugin. My Audiocast will play and play and play from the Audiocast app on by phone (usually, connect Pandora). So I don't think it is the Audiocast.
    I can also connect to it using Bubbleupnp app, and it will respond, just not this plugin after a "timeout", I'm guessing
    I read on this forum that DLNA standard want the renderer to send a periodic "alive" message, and it is possible that the Audiocast doesn't do this, so the plugin thinks it is disconnected, which may be why your songs stop. Just a guess.
    I was wondering if dcorsus, the plugin author could eliminate this requirement and the audiocast would work.
    Can you use the Audiocast outside of the plugin? How does it work in that situation?

    Bruce

    Comment


      #3
      Originally posted by dbvanb View Post
      Hi,
      I have a similar circumstance. I also use the Audiocast as the DMR, but it will only respond to the plugin if the plugin has been stopped and restarted, or if the Audiocast has been powered off and on. Otherwise, it says "Activated - offline" and it won't respond to the plugin. My Audiocast will play and play and play from the Audiocast app on by phone (usually, connect Pandora). So I don't think it is the Audiocast.
      I can also connect to it using Bubbleupnp app, and it will respond, just not this plugin after a "timeout", I'm guessing
      I read on this forum that DLNA standard want the renderer to send a periodic "alive" message, and it is possible that the Audiocast doesn't do this, so the plugin thinks it is disconnected, which may be why your songs stop. Just a guess.
      I was wondering if dcorsus, the plugin author could eliminate this requirement and the audiocast would work.
      Can you use the Audiocast outside of the plugin? How does it work in that situation?

      Bruce
      dbvanb and jccook200

      So I cannot change the standard, UPNP is built on subscriptions and renewals before they time out. So far this PI probably has worked against hundreds of different devices and this is a first. I checked my implementation against the standard again, and I think everything is done right. However the standard says that the server can return a status 412 Precondition Fail if there is something wrong with the renew. Any chance you guys can take a trace?

      I would need you to turn the UPNP debug level to VERBOSE
      Restart the PI
      Let is discover the Audiocast and then I believe after the first refresh (<30 min later), the Audiocast will go to off-line status.
      Go to the log, which will be pretty big and filter first on: AddCallback and cut/paste the info here and then filter on SendRenew and cut/paste the info.

      I want to see if the response from the Audiocast to the callback has something specific in it, that it may expect to receive each time a renew is sent.

      Thanks,

      Dirk

      Comment


        #4
        Thanks, Dirk,

        I should be able to try this over the weekend.
        I know you can't change the standard, but if the plugin didn't care about the timeout, would that work?
        It doesn't seem like the Audiocast app or the BubbleUPnp seem to care about the timeout, they will just
        pickup and start playing no matter how long they have been turned off. Or maybe when I start the app on my
        phone, it is like restarting the plugin here. Hmmmmm.

        Bruce

        Comment


          #5
          Originally posted by dbvanb View Post
          Thanks, Dirk,

          I should be able to try this over the weekend.
          I know you can't change the standard, but if the plugin didn't care about the timeout, would that work?
          It doesn't seem like the Audiocast app or the BubbleUPnp seem to care about the timeout, they will just
          pickup and start playing no matter how long they have been turned off. Or maybe when I start the app on my
          phone, it is like restarting the plugin here. Hmmmmm.

          Bruce
          I assume your bubbleupnp is the server here not the controller, can you confirm? If it is the controller, perhaps we should trace it to see how it communicates.
          The Audiocast App, is this a controller or a player? If it is a controller, maybe it doesn't use UPNP to control.
          What we are talking about is a TCP connection between a player or server and a controller. This is a connection to allow a player or server to autonomously inform a controller about events (start play, track info, content change etc etc). If you don't have this the controller would have to continuously poll the device, so this is critical in a UPNP/DLNA solution.
          No you should not disable the timeout because without it, you have no idea whether the other side of this TCP connection is still there. I'm absolutely sure none of the UPNP/DLNA parts of your network would not do this.
          Dirk

          Comment


            #6
            Dirk
            Ok, Sorry about the confusion. If the timeout is a necessary part of the DLNA, then bubbleupnp and the audiocast app (on my phone or tablet) should be honoring that, but I am just a user, so what do I know.
            Here is my set up:
            The audiocast hardware is the renderer or player (connected to the speakers). The audiocast App on my phone, i don't think is a server, because I can shut down the app (or even turn the phone off) and the hardware still plays, once I've connected to a server, IE Pandora or my computer with minidlna server to serve my local library. The bubbleupnp is similar, I think as it just connects my audiocast hardware player to a server, IE minidlna.
            Currently (at this very moment), I am playing pandora through the audicast, which was started by the audiocast app on my phone. The Plugin Audiocast device in the device management page of homeseer shows "activated-offlilne". The last time it shows active or a change in the "last change" column is when I restarted Homeseer, which I do every other night at 3:30am. It shows the yellow check mark in the plugin config page.

            So now, I am going to turn off the Audiocast, start the Debug and restart the plugin to see if I can capture anything in the log for you.
            Thanks for looking into this
            Bruce

            Comment


              #7
              Well, Just playing around and I am not sure about this behavior of the Audiocast Hardware renderer.

              If I pause the Audiocast App on the phone and exit, then start BubbleUpnp app on the phone and hit play it will unpause the
              song that was playing on the Audiocast App, like there is a setting in the hardware that is set. The bubbleUpnp will not update
              the now playing however.

              If i unplug the Audiocast hardware, and restart it, it will just start back up at the last song from the Audiocast App, even though
              I start the bubbleupnp app.

              If I restart the plugin, while the audiocast hardware is playing, It will show acitvated-online, and it will show what is now playing and change with the change of songs for one or two songs, then it becomes unresponsive, going back to activated off-line.

              I am repeating this to see how many songs before the plugin stops registering, then I will know how long to leave the debug flag on
              Bruce

              Comment


                #8
                Dirk,
                Here is the debug log file. It seems to lose connection after about 4-5 minutes. I did play with controlling the Audiocast from the plugin during this time. Changed the volume. I put stars around the time when the plugin lost contact with the Audiocast hardware. It was playing music the whole time.
                Hope this helps.
                As an aside, even when the plugin lost contact with the hardware, the track length kept updating: ie a time just kept going - did not reset with a new song or anything. Everything else would not respond.
                Thanks again
                Bruce

                MC-debug-log.txt

                Comment


                  #9
                  Originally posted by dbvanb View Post
                  Dirk,
                  Here is the debug log file. It seems to lose connection after about 4-5 minutes. I did play with controlling the Audiocast from the plugin during this time. Changed the volume. I put stars around the time when the plugin lost contact with the Audiocast hardware. It was playing music the whole time.
                  Hope this helps.
                  As an aside, even when the plugin lost contact with the hardware, the track length kept updating: ie a time just kept going - did not reset with a new song or anything. Everything else would not respond.
                  Thanks again
                  Bruce

                  [ATTACH]n1265260[/ATTACH]
                  Hi Bruce, could you do the following;

                  I would need you to turn the UPNP debug level to VERBOSE
                  Restart the PI
                  Let is discover the Audiocast and then I believe after the first refresh (<30 min later), the Audiocast will go to off-line status.
                  Go to the log, which will be pretty big and filter first on: AddCallback and cut/paste the info here and then filter on SendRenew and cut/paste the info.

                  Thanks,

                  Dirk

                  Comment


                    #10
                    Ok Dirk,

                    Here is the new debug file. Actually two.
                    MC-debug-log2.txt is the filtered on AddCallback and SendRenew.
                    MC-debug log3.txt is the unfiltered log, only from just before the Audiocast disconnected and the debug flag turned off.

                    Hope this helps.
                    Thanks
                    Bruce

                    MC-debug-log3.txt
                    MC-debug-log2.txt
                    Attached Files

                    Comment


                      #11
                      Originally posted by dbvanb View Post
                      Ok Dirk,

                      Here is the new debug file. Actually two.
                      MC-debug-log2.txt is the filtered on AddCallback and SendRenew.
                      MC-debug log3.txt is the unfiltered log, only from just before the Audiocast disconnected and the debug flag turned off.

                      Hope this helps.
                      Thanks
                      Bruce

                      MC-debug-log3.txt
                      MC-debug-log2.txt
                      Thanks Bruce. Did you wait long enough? I only see less than a minute of log info so I would expect to see at least many minutes between start up and disconnect
                      Comments?
                      Dirk


                      Comment


                        #12
                        Originally posted by dcorsus View Post

                        Thanks Bruce. Did you wait long enough? I only see less than a minute of log info so I would expect to see at least many minutes between start up and disconnect
                        Comments?
                        Dirk

                        Actually between the 2 traces I think I have what I was looking for (sorry doing this on my phone right now)
                        At first glance I see nothing wrong :-( I’ll study it better once I’m in front of my computer
                        Dirk

                        Comment


                          #13
                          Originally posted by dbvanb View Post
                          Ok Dirk,

                          Here is the new debug file. Actually two.
                          MC-debug-log2.txt is the filtered on AddCallback and SendRenew.
                          MC-debug log3.txt is the unfiltered log, only from just before the Audiocast disconnected and the debug flag turned off.

                          Hope this helps.
                          Thanks
                          Bruce

                          MC-debug-log3.txt
                          MC-debug-log2.txt
                          dbvanb

                          At home now.

                          Can you check that you had log entries around 11:36:07 (+-30 seconds). The log entries you captured in log3, shows the device going off-line but this shouldn't have been the first renew, it is actually the second. The first one should have been sent around 11:36:07 and I'd be curious to find out whether that was successful or not. Reason this is important is that the second renew at 11:38:57 is beyond the timeout and could be the reason why we receive a precondition fail.

                          If you can't find the log anymore, please make me ONE log from start of HS until the Audiocast disconnects .

                          Thanks,

                          Dirk

                          Comment


                            #14
                            Hi Dirk,
                            Sorry for the delay, just got time to look at this tonight.
                            Here is the log around 11:36
                            It seemed like it was long enough, as I was watching the device management, and I could see when the
                            plugin was no longer responding.

                            I have the whole log if you need that, or I can run it again.
                            Thanks
                            Bruce

                            MC-debug-log-11:36.txt

                            Comment


                              #15
                              Originally posted by dbvanb View Post
                              Hi Dirk,
                              Sorry for the delay, just got time to look at this tonight.
                              Here is the log around 11:36
                              It seemed like it was long enough, as I was watching the device management, and I could see when the
                              plugin was no longer responding.

                              I have the whole log if you need that, or I can run it again.
                              Thanks
                              Bruce

                              [ATTACH]n1265968[/ATTACH]
                              Well I don't see my first renewal, what's up with that
                              Maybe post the whole log or PM it to me.
                              Probably asked you a few time but what OS is this running on? If Windows, all .NET patches are up to date?

                              Comment

                              Working...
                              X