Jumpy Plugin (26 October 2016)

[Bobbylala]

That did the trick. Awesome! Thank you so much for the help!

[infidel]

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:

Code: Select all

refresh_needed=false

[Casper]

Code: Select all

refresh_needed=false

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).

[infidel]

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.

[DeFlanko]

Infidel, you're the troubleshooter of the year...

[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.

[infidel]

Infidel, you're the troubleshooter of the year...

Thx, also no trouble shooting myself in the foot often...

[ExSport]

[*]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

[infidel]

http://www.ps3mediaserver.org/forum/vie ... 201#p76099

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.

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:

  [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:

  Code: Select all

  ChunkedTransfer=true

Also, as you've already gleaned the only difference between the a3-testpan2 update.jar and the original is the extra debug info .

[Casper]

[New I/O worker #6] Network debugger: ... MPEG_PS_PAL;DLNA.ORG_OP=01 size=...

All videos are listed with DLNA.ORG_OP=01

Code: Select all

ChunkedTransfer=true

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.