Page 34 of 80
Re: Jumpy Plugin (7 August 2013)
Posted: Fri Aug 30, 2013 1:35 am
by Bobbylala
That did the trick. Awesome! Thank you so much for the help!
Re: Jumpy Plugin (7 August 2013)
Posted: Fri Aug 30, 2013 4:49 am
by infidel
Casper wrote:I meant that as a hopeful remark
, the listing problem persists.
Better slim than none when it comes to hope
. Try repeating the last test, but this time add to
jumpy.conf:
Re: Jumpy Plugin (7 August 2013)
Posted: Sun Sep 01, 2013 6:21 pm
by Casper
Success!
Thanks for your extra effort getting my Derpasonic working infidel, hopefully others will also benefit.
I'm guessing logs are not necessary now but I attached one anyway just in case.
FYI Jumpy testpan3 appears to have reintroduced the previous Panasonic playback problem with resolve_at_playback=true (independent of refresh_needed value).
Re: Jumpy Plugin (7 August 2013)
Posted: Mon Sep 02, 2013 5:54 am
by infidel
Casper wrote:Success!
Let the good times scroll
!
Thanks for patience vis the long distance debugging. The Panasonic seems to take things very literally and is not at all shy about going ballistic when things go wrong. Here's a recap of what we tried:
- TotalMatches: although this was the source of the original bombardment issue you cited, it wasn't the problem here since the logic is internal to UMS and not influenced by jumpy, as confirmed by the extra debug output.
- Add bookmark: because jumpy was waiting to see if a folder actually contained any items before creating 'Add bookmark' as the last item and then moving it to the top of the list, its dlna id was out of sequence. It's not clear whether the Panasonic had a problem with this since there were other issues too.
- DLNA.ORG_OP flag: in the "resolve at playback" scenario the initial item sent to the Panasonic is a tentative placeholder, since the final details aren't known yet. Due to internal UMS logic these initial items were assigned a DLNA.ORG_OP=10 (seek by time) flag, which the Panasonic doesn't seem to like. I modified jumpy to create initial items such that UMS would assign DLNA.ORG_OP=01 (seek by byte), which apparently makes the Panasonic happy.
- UpdateID: jumpy's folders were intentionally pretending to always need updating, which on some renderers (e.g. my Sony Bluray but not xbmc) results in the folder being refreshed as soon as it's modified (for instance when you press 'Delete bookmark' and re-enter the containing folder you'll see the deleted bookmark disappear). With the Panasonic this causes it to (naturally enough) throw out what it just received and request the new stuff as advertised, and on and on and on. Jumpy's probably more to blame here, since it's trying to be slick.
I'll try to see if anything here would have made a difference vis. playback.
Re: Jumpy Plugin (7 August 2013)
Posted: Mon Sep 02, 2013 11:16 am
by DeFlanko
Infidel, you're the troubleshooter of the year...
Re: Jumpy Plugin (7 August 2013)
Posted: Mon Sep 02, 2013 10:55 pm
by Casper
Thanks for the detailed post-mortem. I previously saw mention of problems with Panasonic and seek by time so I tried changing the variable in Panasonic.conf, default value
exclusive to
false but with no difference.
The resolve at playback problem only reappeared in Jumpy testpan3. I have gone back to Jumpy testpan2 and both playback works and listing works with
refresh_needed=false. I have also reverted back to UMS a3 update2 and everything appears to be working well.
Re: Jumpy Plugin (7 August 2013)
Posted: Tue Sep 03, 2013 12:02 am
by infidel
DeFlanko wrote:Infidel, you're the troubleshooter of the year...
Thx, also no trouble shooting myself in the foot often...
Re: Jumpy Plugin (7 August 2013)
Posted: Tue Sep 03, 2013 12:13 am
by ExSport
infidel wrote:[*]DLNA.ORG_OP flag: in the "resolve at playback" scenario the initial item sent to the Panasonic is a tentative placeholder, since the final details aren't known yet. Due to internal UMS logic these initial items were assigned a DLNA.ORG_OP=10 (seek by time) flag, which the Panasonic doesn't seem to like. I modified jumpy to create initial items such that UMS would assign DLNA.ORG_OP=01 (seek by byte), which apparently makes the Panasonic happy.
http://www.ps3mediaserver.org/forum/vie ... 201#p76099 
Re: Jumpy Plugin (7 August 2013)
Posted: Tue Sep 03, 2013 1:39 am
by infidel
Thx, ExSport, you're the man on all things Panasonic
. Casper's report seems to be consistent with both
01 and
10 being valid for the Panasonic as you point out. The remaining problem is why playback is stopping early on some web items.
Casper wrote:The resolve at playback problem only reappeared in Jumpy testpan3. I have gone back to Jumpy testpan2 and both playback works and listing works with refresh_needed=false.
so
- what is the DLNA.ORG_OP setting for an item when playback (eventually) fails vs when it works:
debug.log wrote:[New I/O worker #6] Network debugger: ... MPEG_PS_PAL;DLNA.ORG_OP=01 size=...
- In the testpan3 scenario, does adding this setting to Panasonic.conf make any difference:
Also, as you've already gleaned the only difference between the a3-testpan2
update.jar and the original is the extra debug info
.
Re: Jumpy Plugin (7 August 2013)
Posted: Wed Sep 04, 2013 11:42 pm
by Casper
infidel wrote:debug.log wrote:[New I/O worker #6] Network debugger: ... MPEG_PS_PAL;DLNA.ORG_OP=01 size=...
All videos are listed with DLNA.ORG_OP=01
For Jumpy testpan3, enabling ChunkedTransfer in Panasonic.conf fixed the problem. I tried the same thing with XBMC and it works there too.
Out of curiosity I went back to 0.2.8 (still with UMS 3.0.0-a3-update2) and couldn't reproduce the playback problem (xbmc-test-130813 seems unrelated after all) so I have to do more testing. I definitely get the problem with UMS 2.6.5 & Jumpy 0.2.8 and ChunkedTransfer fixes it there also.