Jumpy Plugin (26 October 2016)

[infidel]

Update: jumpy-0.2.8

[Denbo]

Update: jumpy-0.2.8

FYI:
Had a problem running jumpy 2.8 with PS3 Media Server 1.90.0 log file complains after ” jumpy: Adding root folder.” Couldn’t find \jumpy\lib\winp.dll , The workaround was to run PS3 Media Server as administrator once.

[infidel]

Had a problem running jumpy 2.8 with PS3 Media Server 1.90.0 log file complains after ” jumpy: Adding root folder.” Couldn’t find \jumpy\lib\winp.dll , The workaround was to run PS3 Media Server as administrator once.

Thanks, it's come up before. You've already figured this out , but just for the record:

If you're not running as administrator try switching to an admin account and running UMS once from there. winp-1.14.jar needs to unpack itself (and extract the missing dll) the first time it's loaded, which may not have happened if you don't have admin rights.

EDIT: fixed in the next version's auto-installer, but the above will still apply to fresh manual installs of course.

[Casper]

I'm having a playback problem with 0.2.8 that I didn't have with 0.2.7. Playback is quickly catching up with the buffer and when it does (within about a minute) it stops prematurely, exiting as though completed.

To confirm I did a clean reinstall of UMS with Jumpy 0.2.7 and playback worked with no problem, then updated to 0.2.8 and the problem appeared again with nothing else having changed. I also tried adding/removing PMSEncoder and tested with UMS 2.6.5, 3.0.0 a1 & a3 with no difference.

In all of these logs playback stopped soon after starting:

I had previously noticed this playback problem when testing Jumpy 0.2.7 with XBMC (on the same PC) but my Panasonic TV worked. Now with 0.2.8 both XBMC and the Panasonic TV have the same problem. I previously tried to address the XBMC problem by tweaking the associated conf file but none of my alterations fixed the problem.

While testing Jumpy with XBMC, internet activity looked good and continued for some time after playback had stopped prematurely, indicating the data was available but wasn't being relayed fast enough. I do not have this problem with XBMC (on PC) or UMS web feeds (using PMSEncoder accessed via XBMC on PC or Panasonic TV) so there is no CPU or network bottleneck. Only Jumpy has this problem.

On a related note I noticed with Jumpy 0.2.7 that internet activity was sometimes lower than what it should be which causes poor playback (pausing and buffering). PMSEncoder helped improve internet usage and playback reliability.

[infidel]

Playback is quickly catching up with the buffer and when it does (within about a minute) it stops prematurely, exiting as though completed.

To confirm I did a clean reinstall of UMS with Jumpy 0.2.7 and playback worked with no problem, then updated to 0.2.8 and the problem appeared again with nothing else having changed.

Enough logs to make one's head swim, and of course the behaviour won't reproduce for me .

First, I should point out that jumpy only retrieves links and is completely out of the picture at playback time. Its only possible impact on playback is the specifics of the link itself (eg which CDN, what keys/parameters and so on). There would be no differences that I can think of between 0.2.7 and 0.2.8 in this respect. Needless to say jumpy has nothing to do with the renderer streaming details.

Some things to try which may help narrow the issue (even though they wouldn't explain the 0.2.7/8 difference):

• If you're using tunlr, try disabling it. They were experiencing network dropouts last week and I was getting similar playback problems even on non-geosensitive links which went away when I switched back to opendns. I just tried them again today, though, and everything seemed ok.
• Do WEB.conf youtube links have this problem? If so try disabling xbmc-resolver in jumpy/lib/resolver.py and see if using slightly different urls from youtube-dl makes any difference:

  Code: Select all

  ################# configuration: use True/False #################
  enable_xbmc = False
  enable_youtube_dl = True
  #################################################################

• Try both reducing and increasing the transcode buffer size.
• Try disabling resolve_at_playback (undocumented) in jumpy.conf:

  Code: Select all

  resolve_at_playback = false

If you can pin it down to a simple A/B scenario for the same link it might help, needless to say.

On a related note I noticed with Jumpy 0.2.7 that internet activity was sometimes lower than what it should be which causes poor playback (pausing and buffering). PMSEncoder helped improve internet usage and playback reliability.

Two things:

• Resolving: pmsencoder uses youtube-dl to resolve WEB.conf youtube links, whereas jumpy (via UMS URLResolver interface) uses xbmc-urlresolver>plugin.video.youtube by default, so the final links may be different.
• Playback: pmsencoder always generates an ffmpeg command to transcode to -target ntsc-dvd, i.e. 720x480, whereas FFmpeg Web Video tries to transcode at or near the source resolution, which is of course more resource-intensive when it comes to HD and may explain why pmsencoder is smoother. Jumpy has nothing to do with any of this.

That's all that springs to mind for now, will keep testing.

[S7eele]

The Navi-X 0.3.6 plugin (video addon) appears to work fine in XBMC and Jumpy. You don't need the Navi-X script (program addon) installed

I am wondering if I could leave the updated script add-ons and just keep the old version 3.7.6 video add-on

@S7eele: afaict this should work, I just tried the addon (0.3.6 addon co-installed with separate Navi-X script 3.7.8) and didn't experience the issues you had, i.e. the addon worked the same in jumpy and xbmc to the extent I tested it.

@infidel - thx so much, ill give it a try tonight

EDIT: @infidel - I understand you have many issues that supercede this one so just asking you to give it some thought when and if you get some time. I don't NEED it of course but if you have a moment maybe you could look at Mash-Up. Seems like this add-on is trying to incorporate many other add-ons into theirs as "built-in" plugins. Could be a nice way to consolidate, no biggie for sure!

[infidel]

if you have a moment maybe you could look at Mash-Up.

Well, same answer as with Navi-X (after a quick look ). Mash-up (1.3.6) seems to be working afaict.

[Casper]

Thanks for your help infidel. Adding resolve_at_playback=false in jumpy.conf completely fixed the playback problem for XBMC with 0.2.7 and both XBMC & Panasonic with 0.2.8. The only thing is now I have to go through another menu level to get to the video proper which takes a little extra clicking and waiting.

Regarding your other suggestions:

• tunlr was the first thing I disabled.
• WEB.conf youtube links play fine but enable_xbmc=False in resolver.py did not help.
• Adjusting transcode buffer size also did not help.

I'm now using UMS 3.0.0-a3 with Jumpy 0.2.8 without PMSEncoder. FFmpeg Web is not working so I'm falling back on MEncoder.

I also noticed in XBMC that when resolve_at_playback=true the list is alphabetically sorted which is not desirable as it means 'Add Bookmark' is not guaranteed to be at the top and any ranking by the addon is lost. This doesn't happen on Panasonic TV, the list is never sorted alphabetically regardless of the value of resolve_at_playback.

[infidel]

Adding resolve_at_playback=false in jumpy.conf completely fixed the playback problem

Thx, this gives me something concrete to go on .

I'm now using UMS 3.0.0-a3 with Jumpy 0.2.8 without PMSEncoder. FFmpeg Web is not working so I'm falling back on MEncoder.

See below.

[infidel]

A couple of things to get ffmpeg web functioning properly:

• UMS 3.0.0-a3 only:
  • There are a couple of downstream fixes that need to be present for ffmpeg web video to work right. Placing this update.jar next to ums.jar should fix things for now:

    update2-a3.zip

    (56.58 KiB) Downloaded 1320 times

    NOTE: don't forget to remove this update when installing the next version of UMS.
• All versions:
  • Disable the youtube filter in ffmpeg.webfilters (located in your profile folder next to UMS.conf) by placing '#' at the beginning of its line in the EXCLUDE section:

    #gdata\.youtube\.com|youtube_gdata