search

hzeller / gmrender-resurrect

Resource efficient UPnP/DLNA renderer, optimal for Raspberry Pi, CuBox or a general MediaServer. Fork of GMediaRenderer to add some features to make it usable.
GNU General Public License v2.0
842 stars 204 forks source link

Help Needed? #44

Open stephenfin opened 10 years ago

stephenfin commented 10 years ago

I'm currently using this library and I'm pretty impressed by it...good work! Out of curiosity though are there any enhancements you're planning on making or other things that people can assist with?

hzeller commented 10 years ago

Hi Stephen Thanks for your interest in helping out. Yes, there are number of things that could be improved

The first two things might be interesting starter-projects, the testing thing might be a bit more involved (but is sufficiently stand-alone, that it is easy to not run into merge conflicts)

1) Show current status: The renderer has a way to expose some internal state via some 'presentation_url' (grep for that in the source). This should at least display the name/version etc. of the renderer at first, but later on some (read-only) view of recently played pieces.

2) There are some feature requests that might be useful for some people (e.g. issue #5 , scrobbling to LastFM), that I haven't gotten around implementing yet.

3) Testing: right now, there are no tests, but there are many different UPnP controller out there, that want to communicate with the renderer. Sometimes, these are very picky regarding the protocol, sometimes they just have certain expectations. There were subtle problems in the past with incorrect set namespaces, that would prevent some clients from working. It would be good if there was some kind of end-to-end test, in which we simulate a controller (the libupnp should be able to do that or maybe some plain socket-connection) and we compare the resulting XML with some string/file that contains how it is 'supposed' to be looking.

There are certainly other things you might come up with when reading the code. I inherited the code and already did a couple of cleanups, but there is more that probably can be simplified. But that is something when reading the code and probably discussing offline (I wish github would provide a mailing list, I should probably start one somewhere). There is currently a pull request open by @ademenev which I am reviewing right now - it will add OpenHome functionality to gmrender-resurrect - more exciting features coming :) Andrey expressed interest in continuing to contribute as well.

stephenfin commented 10 years ago

Sounds good. I'll most likely look at testing to get me familiar with the code. I didn't spot any unit tests so I'll try to throw together something using GNU Autotest (I think that's best since you're already using GNU Autotools in the form of Automake/Autoconf?). Integration tests (like you described) would definitely be one for the future though.

With this in mind, any pointers on what you're using as a UPnP specification? Is it your own knowledge or could you point me to some documentation? Would be very useful to understand the standard (UPnP Renderer) well.

PS: You should probably throw your reply above up on the README under "Contributing" or what not - doubt I'm the only person with an interest in this project :)

PPS: Also you can close this now naturally

hzeller commented 10 years ago

I have no experience with GNU Autotest, you need to explore that. I was using mostly googletest so far, but that is for C++ projects, less useful here.

The UPnP specification I got from the UPnP website: http://upnp.org/resources/upnpresources.zip These are nice PDFs that explain all parts of the protocol. Sometimes I refer to sections or pages in these PDFs in the code.

Just mail me privately for further discussion, might be easier.

stephenfin commented 10 years ago

Sounds good. I'll follow up by mail.