{5} Assigned, Active Tickets by Owner (Full Description) (13 matches)
List tickets assigned, group by ticket owner. This report demonstrates the use of full-row display.
dev
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #102 | Plenty of error messages running Rhythmbox | Core | 1.0 | defect | 11.10.2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I get this a good number of times after running Rhythmbox with the Coherence plugin running: WARN device Oct 11 21:33:07 wow, we lost an event subscription for monkey.hadess.net: MythTV AV Media Server urn:upnp-org:serviceId:CMGR_1-0, 'maybe we need to rethink the loop time and timeout calculation?' (coherence/upnp/core/device.py:125) WARN device Oct 11 21:33:07 wow, we lost an event subscription for monkey.hadess.net: MythTV AV Media Server urn:upnp-org:serviceId:CDS_1-0, 'maybe we need to rethink the loop time and timeout calculation?' (coherence/upnp/core/device.py:125) WARN device Oct 11 21:33:27 wow, we lost an event subscription for monkey.hadess.net: MythTV AV Media Server urn:upnp-org:serviceId:CMGR_1-0, 'maybe we need to rethink the loop time and timeout calculation?' (coherence/upnp/core/device.py:125) WARN device Oct 11 21:33:27 wow, we lost an event subscription for monkey.hadess.net: MythTV AV Media Server urn:upnp-org:serviceId:CDS_1-0, 'maybe we need to rethink the loop time and timeout calculation?' (coherence/upnp/core/device.py:125) [etc.] |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #53 | log filtering per device and/or IP | Core | 1.0 | enhancement | 01.02.2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
enable the filtering of log output, so we can restrict it to messages addressing a specific local device or to messages originated from a specific foreign device or IP address |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #94 | propagate devices and services via D-Bus | Core | 1.0 | enhancement | 01.08.2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #148 | implement transcoding for media files | MediaServer Server | 0.7 | enhancement | 06.07.2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
maybe using gentrans? |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #20 | write more unit tests | Coherence - across the board | 1.0 | task | 07.11.2006 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Read my lips: "We need unit tests!" |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #165 | create document based on the OGG Vorbis one | DLNA Dirac proposal | task | 15.11.2008 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #133 | Discussion: control flow within coherence | Core | 1.0 | defect | 29.04.2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
In a couple of places the global coherence object is provided to low level classes so they have access to data structures or can callback with changes. This makes it harder to develop test cases to test functionality in isolation. One example is the event server (event reception) is passed the global object so it can call to proopgate event changes, this propogate then access global data in services to locate the service to deliver the event to. This task is started by calling into upnp.core.event by upnp.core.service to subscribe to the events. In this case I would propose moving the subscribe list in upnp.core.service into upnp.core.event and leaving the later to manage the list. The control flow for events then does not need to know about top level coherence object, event propogation goes in a more direct route to the service. The attached is a copy of upnp.core.event with this proposal, I have not attached the changes to remove this from service and base. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #5 | find usable time for service subscription renewal loop | UPnP Event SubSystem | 1.0 | enhancement | 02.10.2006 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Currently the control point checks every 5 seconds (was 2 seconds before ) if there is a service subscription which needs renewal. As we check whether the subscription times out within 30 seconds, and a usual timeout is 300 seconds it should be sufficient to run this every 20 seconds to not lose any subscription. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #33 | react on FileSystem changes and propagate them | MediaServer Backend FileSystem | 1.0 | enhancement | 30.11.2006 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The FileSystemStore? should react on changes in its directory tree and propagate them to connected ContentDirectory clients.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #35 | better react on 'only' name changes | MediaServer Backend FileSystem | 1.0 | enhancement | 02.12.2006 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
the FileSystem? backend currently only reacts on creating/moving-in or deleting/moving-from of a file or directory. A 'only' name change slips through at the moment. Detecting the corresponding moving-from/moving-in events could result in only updating the name in the UPnP object and save us from deleting and recreating the FileSystem? object. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #134 | Discussion: separating functionality to ease unit testing | Core | 0.7 | enhancement | 29.04.2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The top level coherence object is both application starter and repository of functionality and data that could be separated out and simplify testing. Two items: The list of known devices (Actually root devices) The main users of this is the control point in, that therefore has to know about the coherence main object. Suggest separate into a device_list class. This could then be either part of the upnp.core package, even a singleton. Similarly the coherence object is the web server, this could be separated into its own class. similarly this means that low level classes do not need to know about the top level object. I have found any time you have a set of packages where the dependancies are in a loop testing becomes a problem. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #13 | verify 0.5 sec loop for moderated event propagation | UPnP Event SubSystem | 1.0 | task | 01.11.2006 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Check whether 0.5 seconds is a usable number for the moderated event propagation loop in service.py |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #126 | Use of USN as device identifier. | Core | 1.0 | task | 09.04.2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Raising here to capture the issue: Currently the usn from a ssdp discovery is used to identify a device. This causes problems where the device description contains embedded devices, not just a root device, e.g. Sonos. [Attached is the disocovery log for Sonos and full device and service description set.] I think it better to use the udn that comes from the device description as the device identifier. These are guaranteed unique, if the maufacturer gets it right. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
