Twonky 5.1.9 directory access fails on first directory

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Twonky 5.1.9 directory access fails on first directory

Scott Jackson
In Cling 1.0.5, against a Twonky Media Server 5.1.9, directory browsing fails with respect to the first listed directory in the top-level.

Failure discovered using an android application which employs cling as its backend, and confirmed on cling workbench for 1.0.5.

Failure does not exist with respect to cling 2.0-a2.
Reply | Threaded
Open this post in threaded view
|

Re: Twonky 5.1.9 directory access fails on first directory

bergstr
Scott Jackson wrote
Failure does not exist with respect to cling 2.0-a2.
so then its fixed, isn't it? AFAIK cling 1.0.5 is no longer supported, users are expected to migrate
Reply | Threaded
Open this post in threaded view
|

Re: Twonky 5.1.9 directory access fails on first directory

Scott Jackson
I had no idea users were expected to migrate. Cling 1.0.5 is listed as the "stable" version, and 2.0-a2 is  "testing" and "alpha".

There's no indication on the cling page that 1.0.5 is deprecated and every indication that 2.0-a2 is not deployment-ready.
Reply | Threaded
Open this post in threaded view
|

Re: Twonky 5.1.9 directory access fails on first directory

Scott Jackson
Anyway, I'm hoping for a resolution of this issue on the stable branch... if 1.0.5 is deprecated it should be marked deprecated, and not "stable". If 1.0.5 is stable, then all bug fixes should be incorporated into the stable branch such that it is maintained as stable.

Here's a log that might be helpful to tracking this down. It corresponds to initiating a ContentDirectory browser, expanding the second directory, then expanding the first directory. The second directory succeeds, the first fails. Please Note: The first directory only has 12 sub-folders, but often takes a longer time to respond via HTTP, possibly because of Twonky prefecting 27,689 sub-elements from the sub-folders. It does NOT return these elements over XML, so this is NOT related to the getDefaultMaxResults() issue:

FINE - 10:27:03:387 - AWT-EventQueue-0 : contentdirectory.callback.Browse.<init> : Creating browse action for object ID: 0
FINE - 10:27:03:400 - AWT-EventQueue-0 : plugins.contentdirectory.MediaRendererAdapter.updateMediaRenderers : Updating media renderers
FINE - 10:27:03:400 - AWT-EventQueue-0 : plugins.contentdirectory.MediaRendererAdapter.updateMediaRenderers : Mediarenderers found in local registry: 0
FINE - 10:27:03:422 - cling-22 : contentdirectory.callback.Browse.success : Successful browse action, reading output argument values
FINE - 10:27:03:436 - cling-22 : support.contentdirectory.DIDLParser.parse : Parsing DIDL XML content
FINE - 10:27:03:457 - cling-22 : contentdirectory.ui.ContentBrowseActionCallback.received : Received browse action DIDL descriptor, creating tree nodes
FINE - 10:27:03:536 - AWT-EventQueue-0 : contentdirectory.ui.ContentBrowseActionCallback.updateTreeModel : Adding nodes to tree: 3
FINE - 10:27:09:924 - AWT-EventQueue-0 : contentdirectory.callback.Browse.<init> : Creating browse action for object ID: 0$2
FINE - 10:27:09:954 - cling-15 : contentdirectory.callback.Browse.success : Successful browse action, reading output argument values
FINE - 10:27:09:954 - cling-15 : support.contentdirectory.DIDLParser.parse : Parsing DIDL XML content
FINE - 10:27:09:957 - cling-15 : contentdirectory.ui.ContentBrowseActionCallback.received : Received browse action DIDL descriptor, creating tree nodes
FINE - 10:27:09:968 - AWT-EventQueue-0 : contentdirectory.ui.ContentBrowseActionCallback.updateTreeModel : Adding nodes to tree: 8
FINE - 10:27:12:099 - AWT-EventQueue-0 : contentdirectory.callback.Browse.<init> : Creating browse action for object ID: 0$1
SEVERE - 10:27:17:111 - AWT-EventQueue-0 : ContentDirectoryService Browser : Error: Current state of service prevents invoking that action. Connection error or no response received.
Reply | Threaded
Open this post in threaded view
|

Re: Twonky 5.1.9 directory access fails on first directory

Christian Bauer
Administrator
Anyway, I'm hoping for a resolution of this issue on the stable branch… if 1.0.5 is deprecated it should be marked deprecated, and not "stable".

1.0 is not deprecated, that's why it's not marked deprecated. I just don't do any more development on 1.0 and I'm only interested in the 2.0 codebase.

If 1.0.5 is stable, then all bug fixes should be incorporated into the stable branch such that it is maintained as stable. 

Yes, you should do that, it's open source.