Home of the Squeezebox™ & Transporter® network music players.
Page 6 of 6 FirstFirst ... 456
Results 51 to 55 of 55
  1. #51
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    3,305
    Quote Originally Posted by chincheta0815 View Post
    Hi philippe44,

    I am now working with the framework you made for me. I did the first compilation with it and got some compiler messages. I can get rid of them, but I do not wat to break things up. Could you do me a favor an look into them?

    Since this is not working very good in terms of platform dependencies etc. I am left that SendARP out and use now the MAC I am reading from the hue's config info. All I saw is that the mac is only needed for "naming" squeezelite... Can I then also delte the "MakeMacUnique" function?
    for the LINKALL, it's not an issue but you can add #undef LINKALL in resample.c just before the #define LINKALL 1

    for SendARP, this has been a messy piece in the UPnP version that I never corrected. You can do the following

    1- Remove the "ip" member in struct sHB
    2- Change in AddHueDevice, the SendARP line by
    Code:
    	if (SendARP(ip, INADDR_ANY, (u32_t*) Device->sq_config.mac, &mac_size)) {
    3- Add a "in_addr_t ip;" local variable in the function
    4- Change ExtractIP (and declaration)
    Code:
    in_addr_t ExtractIP(const char *URL)
    {
    	char *p1, ip[32];
    
    	sscanf(URL, "http://%31s", ip);
    
    	ip[31] = '\0';
    	p1 = strchr(ip, ':');
    	if (p1) *p1 = '\0';
    
    	return inet_addr(ip);
    }
    5- Change the ExtractIP call by
    Code:
    ip = ExtractIP(location);
    But you can also simply remove it and use the mac address if you have it from the Hue discovery and in that case you can foget the MakeMacUnique as well

    [edit]: let me know when/if you have completed the framework integration, I'll try to compile the version in my environment (I wanted to but I realized this is still the "old" squeeze2hue.c for example, so I stopped for the moment)
    Last edited by philippe_44; 2017-04-29 at 11:48.
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5

  2. #52
    Senior Member
    Join Date
    Jan 2011
    Location
    Germany
    Posts
    242
    Quote Originally Posted by philippe_44 View Post
    let me know when/if you have completed the framework integration, I'll try to compile the version in my environment (I wanted to but I realized this is still the "old" squeeze2hue.c for example, so I stopped for the moment)
    Hi philippe,

    I started with the framework integration. I am not that fast as you are ;o)
    Here is a link to the dropbox: https://www.dropbox.com/s/r0tm2houl5...o-Hue.zip?dl=0

    I would really appreaciate your opinion. I used my newly created libhuec which basically contains the routine for the hue, or shall contain them. To integrate them I added structures as types (huebridge, response, request, lights,...). The type for the bridge is then added to the HBDevice structure in squeeze2hue.h. As always I ran in some initialization issues, since I used pointer in my hue routines...

    I also added some entries to the config.xml. Here you have to insert a different username to steer your hue. An explanation on how to get that can be found here: https://developers.meethue.com/docum...etting-started

    There are tags like "//NEW" in the squeeze2hue file. These are partly temporary as I am still doing some code and conceptional design. Especially the routine for checking whether a bridge has a username and the one for setting the username is missing.

    Now the question: Do you think it would be better not use pointers and change to simple structures? Maybe that is easier, especially in terms of initialization, etc. Depending on the answer I will go on or change things... Could you recommend me where to allocate and free memory for the lights and the huebridge? the lights are planned to be in an array that is part of structure of the bridges...

    [EDIT] The on/off button in the WebGUI of the player switches the lamp with id 2 off.
    Last edited by chincheta0815; 2017-04-29 at 14:43.
    LMS-7.9@solaris. 2x Radio, 2x Duet, 1x Chromecast v1, ShairTunes, 1x Philips Hue System

  3. #53
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    3,305
    Quote Originally Posted by chincheta0815 View Post
    Hi philippe,

    I started with the framework integration. I am not that fast as you are ;o)
    Here is a link to the dropbox: https://www.dropbox.com/s/r0tm2houl5...o-Hue.zip?dl=0

    I would really appreaciate your opinion. I used my newly created libhuec which basically contains the routine for the hue, or shall contain them. To integrate them I added structures as types (huebridge, response, request, lights,...). The type for the bridge is then added to the HBDevice structure in squeeze2hue.h. As always I ran in some initialization issues, since I used pointer in my hue routines...

    I also added some entries to the config.xml. Here you have to insert a different username to steer your hue. An explanation on how to get that can be found here: https://developers.meethue.com/docum...etting-started

    There are tags like "//NEW" in the squeeze2hue file. These are partly temporary as I am still doing some code and conceptional design. Especially the routine for checking whether a bridge has a username and the one for setting the username is missing.

    Now the question: Do you think it would be better not use pointers and change to simple structures? Maybe that is easier, especially in terms of initialization, etc. Depending on the answer I will go on or change things... Could you recommend me where to allocate and free memory for the lights and the huebridge? the lights are planned to be in an array that is part of structure of the bridges...

    [EDIT] The on/off button in the WebGUI of the player switches the lamp with id 2 off.
    Would you mind pushing the modifications you've made (the ones in this dropbox folder) to github? This way, I could offer directly some proposals. Typically, I need to make some non-functionnal changes to make it compile under my Windows environment. If I do that on an independent tree, merging will be difficult and I don't feel like doing these changes more than once.

    In general, I agree with the logic of the response, request, light to be allocated on demand but inside these structures, strings can be of a fixed maximum size. Using pointer for strings inside these structures and allocating/freeing them would add a lot of pain for a modest added value in an application that runs on a reasonably large system. My background is embedded development where every byte counts, but I don't think this is a necessary here.

    One recommendation is to work now on freeing everything you allocate. Don't push that to a later 'cleanup' phase as you'll probably be missing a lot then. It's a personal choice, but I feel it's safer - at every design stage, when I allocate something, I'm adding at the same time the freeing function.

    Having said that, you can also have (eg) the hue_light_t structure being created as a local variable in the stack. That will save you the malloc/free tail chasing and because these structures are small and as everything happens in the PlayerThread, it's fine. If later you want to have the blocking HTTP request/response in another thread, functions like hue_set_light_state can then copy the request in a dynamically allocated structure.

    Code:
    	if (!strcasecmp(req->Type, "CONNECT")) {
                
                hue_ligth_t hueLight;
                hueLight.attribute.id = 2;
                strcpy(hueLight.attribute.name, "Dieter");
            
                hue_set_light_state(Device->bridge_props, &hueLight, SWITCH, "ON");
    	}
    Last edited by philippe_44; 2017-04-29 at 17:15.
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5

  4. #54
    Senior Member
    Join Date
    Jan 2011
    Location
    Germany
    Posts
    242
    Quote Originally Posted by philippe_44 View Post
    Would you mind pushing the modifications you've made (the ones in this dropbox folder) to github? This way, I could offer directly some proposals. Typically, I need to make some non-functionnal changes to make it compile under my Windows environment. If I do that on an independent tree, merging will be difficult and I don't feel like doing these changes more than once.
    Here we go: https://github.com/chincheta0815/LMS-to-Hue
    As requested I pushed the whole dropbox content.

    Quote Originally Posted by philippe_44 View Post
    In general, I agree with the logic of the response, request, light to be allocated on demand but inside these structures, strings can be of a fixed maximum size. Using pointer for strings inside these structures and allocating/freeing them would add a lot of pain for a modest added value in an application that runs on a reasonably large system. My background is embedded development where every byte counts, but I don't think this is a necessary here.
    I totally agree with you. Especially the whole freeing and allocating is a mess to me. Can you recommend some maximum length for the strings?

    [EDIT]I think what you mentioned has happened... I ran into a lot of memleaks which I cannot clear.. They seem to be related to the response & request. I think it might be an issue with the threads. Trying to solve that, I experimented a little bit with mutexes etc. but I could not get that issues...

    Quote Originally Posted by philippe_44 View Post
    One recommendation is to work now on freeing everything you allocate. Don't push that to a later 'cleanup' phase as you'll probably be missing a lot then. It's a personal choice, but I feel it's safer - at every design stage, when I allocate something, I'm adding at the same time the freeing function.
    Do I also have to free "common" variables and structutres or only pointers to them? I read that I only have to "free()" the things I have "malloc()"ed.

    Quote Originally Posted by philippe_44 View Post
    Having said that, you can also have (eg) the hue_light_t structure being created as a local variable in the stack. That will save you the malloc/free tail chasing and because these structures are small and as everything happens in the PlayerThread, it's fine. If later you want to have the blocking HTTP request/response in another thread, functions like hue_set_light_state can then copy the request in a dynamically allocated structure.
    Well, blocking etc. is right now my smallest concern... I am getting quite confused right now.... Maybe it is too much at once...

    Working a little bit with the framework I ran into an issue, that showed up some bug in the code:
    I want to add the feature that the hue is only shown as a LMS player, when a valid username is available, meaning that thing can be controlled. I tried to add a "hue_get_all_capabilities" function into *UpdateHueThread. After AddNewDevice I thought of checking for access and then do a DelHueDevice, but all I got was a segfault... Can you recommend me a way of implementing such a function?

    [EDIT]After all testing and stuff I am a little bit messed up.. I am trying and trying but I cannot get a step forward.. Would you mind showing me how to best avoid memleaks by not using pointers in my code in e.g. the request function or so? I think I need an example...
    Maybe it's even better to avoid pointers totally and declare my functions like "huebridge_t bridge" and not "huebridge_t *bridge"???

    Finally, I think I have an issue with threading...
    Last edited by chincheta0815; 2017-04-30 at 12:27.
    LMS-7.9@solaris. 2x Radio, 2x Duet, 1x Chromecast v1, ShairTunes, 1x Philips Hue System

  5. #55
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    3,305
    Quote Originally Posted by chincheta0815 View Post
    Here we go: https://github.com/chincheta0815/LMS-to-Hue
    As requested I pushed the whole dropbox content.


    I totally agree with you. Especially the whole freeing and allocating is a mess to me. Can you recommend some maximum length for the strings?

    [EDIT]I think what you mentioned has happened... I ran into a lot of memleaks which I cannot clear.. They seem to be related to the response & request. I think it might be an issue with the threads. Trying to solve that, I experimented a little bit with mutexes etc. but I could not get that issues...


    Do I also have to free "common" variables and structutres or only pointers to them? I read that I only have to "free()" the things I have "malloc()"ed.


    Well, blocking etc. is right now my smallest concern... I am getting quite confused right now.... Maybe it is too much at once...

    Working a little bit with the framework I ran into an issue, that showed up some bug in the code:
    I want to add the feature that the hue is only shown as a LMS player, when a valid username is available, meaning that thing can be controlled. I tried to add a "hue_get_all_capabilities" function into *UpdateHueThread. After AddNewDevice I thought of checking for access and then do a DelHueDevice, but all I got was a segfault... Can you recommend me a way of implementing such a function?

    [EDIT]After all testing and stuff I am a little bit messed up.. I am trying and trying but I cannot get a step forward.. Would you mind showing me how to best avoid memleaks by not using pointers in my code in e.g. the request function or so? I think I need an example...
    Maybe it's even better to avoid pointers totally and declare my functions like "huebridge_t bridge" and not "huebridge_t *bridge"???

    Finally, I think I have an issue with threading...
    I've submitted a pull with many changes. I've tested it under SunOS, Windows and Linux and was able to make 10's of play/stop without any error. One of the problem (a very basic pointer error ...) was in the socket receive function I've made for you - I'm really sorry about that, it probably caused a good amount of the issues. I've also removed most of the malloc/free to use local variables. I've also changed the various string sizes in the hue_bridge_structure to a larger default value and use strncpy instead of strcpy. That was also causing various issue as you did not dimension some string large enough (in C, all strings must have an extra byte at the end for the NULL char), so you had some runaway copies.

    I've also change the virtual player creation logic so that entries are created for the config.xml file auto-update (if set on the command line - this will be important in the future when you'll want users to create that username from LMS plugin's settings) but a squeezelite instance will not be created if the hue username is missing. You *must* now set user_name in the config.xml file

    I also removed the mutex because I don't think you need this. There is only one virtual player per hue bridge and the requests are queued, so I don't see, with this architecture, how a conflict can happen (between various LMS requests and/or between an LMS request and a periodic hue bridge discovery). I might have to think about it more, though

    Maybe we can move to PM to continue our discussions
    Last edited by philippe_44; 2017-04-30 at 21:59.
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •