Announcement

Collapse
No announcement yet.

Startup Error - No device Detected

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

    Originally posted by ServiceXp View Post
    You were 100% correct... HOLY COW, I found the problem with the local play back buffering problem! It dawned on me (after thinking about your added direct access feature) that I should probably add port 880 to the Chromecast firewall on the VLAN. Added that and BAMM it works.

    Oh and your direct access addition works perfectly also..


    What ports can I get rid of here?

    Click image for larger version Name:	2020-07-25_12-36-28.png Views:	0 Size:	332.5 KB ID:	1405790
    Great, finally

    I'm not sure about the ports, 8009 is the port used by Chromecast, but it doesn't need to be enabled in Firewall - because as I understand, Firewall controls "incoming" ports. But I'm not an expert in this.

    I think you can remove all, but 880.

    Comment


      Not sure If I should start another thread, but I've noticed some stability issues. After a few announcement the group (in the case House Audio Group) gets stuck into a non-working state.

      Click image for larger version

Name:	2020-07-27_17-49-33.png
Views:	101
Size:	303.5 KB
ID:	1406464

      [ATTACH]n1406465[/ATTACH]
      RJ_Make On YouTube

      Comment


        You'll notice Upstairs Audio Group is also in a non-responsive state.
        RJ_Make On YouTube

        Comment


          Originally posted by ServiceXp View Post
          You'll notice Upstairs Audio Group is also in a non-responsive state.
          I'll check

          Comment


            Code:
            [4836]: * Disconnected from ChromeCastClient (No connection could be made because the target machine actively refused it 192.168.20.86:42498) (Upstairs Audio Group)
            [4836]: * InnerException: No connection could be made because the target machine actively refused it 192.168.20.86:42498 (Upstairs Audio Group)
            
            [4788]: * Disconnected from ChromeCastClient (No connection could be made because the target machine actively refused it 192.168.20.200:42505) (House Audio Group)
            [4788]: * InnerException: No connection could be made because the target machine actively refused it 192.168.20.200:42505 (House Audio Group)
            So it looks like firewall? Are the IPs and Ports correct?

            Comment


              If those are outbound requests (coming from my machine) then I don't think so, as the firewall rules are inbound only.

              I'll have to run that new mDNS utility next time this is happening to confirm the groups IP and Port number. All devices have a fixed IP's and Ports, but the groups move around allot.
              RJ_Make On YouTube

              Comment


                Originally posted by ServiceXp View Post
                If those are outbound requests (coming from my machine) then I don't think so, as the firewall rules are inbound only.

                I'll have to run that new mDNS utility next time this is happening to confirm the groups IP and Port number. All devices have a fixed IP's and Ports, but the groups move around allot.
                Normally the plugin should handle change in IP address assuming the device name didn't change. But I haven't checked for a long time, especially with the new Zeroconf libs. Are you using Mono.Zeroconf (Bonjour service)?

                Comment


                  I had the Zeroconf box ticked.

                  EDIT:
                  I just updated to build .60. Which selection is the new one I tested last week? (Currently Set to Auto)
                  RJ_Make On YouTube

                  Comment


                    Originally posted by ServiceXp View Post
                    I had the Zeroconf box ticked.
                    Ah, you didn't update to .60? It has a list of available providers.

                    Comment


                      I just updated to build .60. Which selection is the new one I tested last week? (Currently Set to Auto)
                      RJ_Make On YouTube

                      Comment


                        It should show - MonoZeroconf means it's using Bonjour

                        Click image for larger version

Name:	Annotation 2020-07-29 005534.jpg
Views:	117
Size:	21.8 KB
ID:	1406716

                        Comment


                          It appears, at least in this case, the group's IP address is changing and the PI is failing to capture it. While in this state I fired up the new mDNS Tester and the Bonjour Browser and both had the correct information. As soon as I restart the PI it also connects the correct IP and Ports.

                          The logs contain the mDNS Tester results also.

                          The group in question this time is the Upstairs Audio Group

                          Click image for larger version  Name:	2020-07-30_5-39-45.png Views:	0 Size:	62.7 KB ID:	1407186

                          AK CC Cli Logs and mDNS info Build .60 PI Group Non-Responsive State.zip
                          RJ_Make On YouTube

                          Comment


                            Yeah, that's what I suspected. Groups can jump from one device to another. The plugin is supposed to capture the IP/Port change - assuming the name didn't change.

                            I need to check. But it's hard to reproduce.

                            [EDIT] It changed from 192.168.20.28:42498 to 192.168.20.86:42498 - but it looks like plugin recognized the change?

                            Then it changed to 28, then to 86 - but it was ok in plugin.

                            The log ends with
                            Code:
                            Resolve 'Google-Cast-Group-f54037988ef241598af3c996aa82ef52'
                            Which usually is followed by
                            Code:
                            *CreateReceiver: Google-Cast-Group-f54037988ef241598af3c996aa82ef52, 192.168.20.86:42498
                            but not in the end of the log. Is it possible you just caught it when it was still resolving?

                            Normally the sequence (4836 is the HS device ref. number):
                            Code:
                            Resolve 'Google-Cast-Group-f54037988ef241598af3c996aa82ef52'
                            ***
                            Resolved name = 'Google-Cast-Group-f54037988ef241598af3c996aa82ef52', type = '_googlecast._tcp.', domain = 'local.'
                            *** Full name = 'Google-Cast-Group-f54037988ef241598af3c996aa82ef52._googlecast._tcp.local.', host ip = ['192.168.20.86'], hostname = '', port = '678' (-23038), interface = '13', address type = 'IPv4'
                            TXT Record:
                            id = 'f5403798-8ef2-4159-8af3-c996aa82ef52'
                            cd = 'f5403798-8ef2-4159-8af3-c996aa82ef52'
                            rm = ''
                            ve = '05'
                            md = 'Google Cast Group'
                            ic = '/setup/icon.png'
                            fn = 'Upstairs Audio Group'
                            ca = '198692'
                            st = '0'
                            bs = 'FA8FCA801FB9'
                            nf = '2'
                            rs = ''
                            _CreateReceiver: Google-Cast-Group-f54037988ef241598af3c996aa82ef52 (_googlecast._tcp.local)
                            *CreateReceiver: Google-Cast-Group-f54037988ef241598af3c996aa82ef52, 192.168.20.86:42498
                            [4836]: * SetState: 'Unknown' (Upstairs Audio Group)
                            [4836]: * (1) Creating speaker GoogleTranslate...
                            [4836]: * (2) SetReceiver HSPI_AKGoogleCast.SpeakerGoogleTransl => ConnectAsync [Google Cast Group] Upstairs Audio Group (192.168.20.86)... (Upstairs Audio Group)
                            [4836]: * Set Receiver '[Google Cast Group] Upstairs Audio Group (192.168.20.86)' (HSPI_AKGoogleCast.DeviceCastRoot)
                            [4836]: * ChromeCastClient: Connected (Upstairs Audio Group)
                            [4836]: * (3) Connecting to Homeseer (hs_speech_client) HSPI_AKGoogleCast.SpeakerGoogleTransl (Upstairs Audio Group) (state retrying)...
                            [4836]: ConnectHSSpeechClient Upstairs Audio Group
                            [4836]: * Speaker Connected (hs_speech_client): Upstairs Audio Group
                            [4836]: * (4) Connected to Homeseer (hs_speech_client) HSPI_AKGoogleCast.SpeakerGoogleTransl (Upstairs Audio Group) (state connected)...
                            [4836]: * SetState: 'Unknown' (Upstairs Audio Group)
                            [4836]: * PlayerState: Idle (Unknown) (Upstairs Audio Group)
                            Where the last line "PlayerState: Idle (Unknown) (Upstairs Audio Group)" means that it successfully communicating with the device because it received the "Idle" state.

                            Comment


                              It did not recognize the change in the PI UI. In the pic I posted, the PI thought the group was at 192.168.20.86 and would not communicate with the group. It was right then I opened the mDNS Tester app and it correctly found the group on 192.168.20.28.

                              Every single time, without exception, shutting the PI down and back on restores any group or device that was previously stuck in this non-communicating mode.

                              EDIT: I would say at this point, I don't Think I've been catching this each time while it was still resolving. If so, It takes a loooong time to resolve.
                              RJ_Make On YouTube

                              Comment


                                Originally posted by ServiceXp View Post
                                EDIT: I would say at this point, I don't Think I've been catching this each time while it was still resolving. If so, It takes a loooong time to resolve.
                                No I don't think it takes long. But still it looks like mDNS issue. I'll see what I can do.
                                In .60 I already changed - so when any device is "lost" - I restart mDNS discovery to speed-up discovering the device back.
                                What I noticed in the log though - the group was lost, then discovery restarted - and during the discovery it was lost again. Probably that's the issue.
                                Can you try TmdsMDns - that's the latest library, may be more stable.

                                Comment

                                Working...
                                X