Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[builtin] adds new builtin for seeking #6801

Merged
merged 5 commits into from
Apr 11, 2015

Conversation

xhaggi
Copy link
Member

@xhaggi xhaggi commented Mar 23, 2015

This adds a new built-in command Seek(<seconds>) to support instant seeking in the current playing media file. @da-anda it should make every small step lover happy ;)

<keymap>
  <FullscreenVideo>
    <keyboard>
      <YOURKEY>Seek(-7)</YOURKEY>
    </keyboard>
  <FullscreenVideo>
</keymap>

Related discussion at http://forum.kodi.tv/showthread.php?tid=217616&pid=1957016#pid1957016

m_percent = m_percentPlayTime + percentPerSecond * seconds;
g_infoManager.SetSeekStepSize(seconds);

if (m_percent > 100.0f) m_percent = 100.0f;

This comment was marked as spam.

This comment was marked as spam.

@da-anda
Copy link
Member

da-anda commented Mar 23, 2015

nice, thanks. Should we extend JSON-Rpc to also support it? It already provides seeking by percentage, absolute time code and small/bigsteps, but no relative seeking with a custom step size. From a quick look it might be a bit tricky to add it there (requires more advanced evaluation of the input params)

@xhaggi xhaggi added the Type: Improvement non-breaking change which improves existing functionality label Mar 23, 2015
@Tolriq
Copy link
Contributor

Tolriq commented Mar 23, 2015

JSON should be able to call the Seek with Input.Action so not a problem for remote makers I guess to use this.

if (g_infoManager.GetTotalPlayTime())
percentPerSecond = 100.0f / (float)g_infoManager.GetTotalPlayTime();

m_percent = m_percentPlayTime + percentPerSecond * seconds;

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

@Paxxi
Copy link
Member

Paxxi commented Mar 23, 2015

What exactly is this trying to solve? looking at the forum thread I get the impression it's to satisfy one users wish to retain old behaviour?

Furthermore, with this being callable from Builtins raises the question of thread safety, there's no protections around state modifications and I'm not sure we know which thread we're called on anymore.

m_analogSeek = false;
m_seekDelay = 0;

if (g_infoManager.GetTotalPlayTime())

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

@Paxxi
Copy link
Member

Paxxi commented Mar 23, 2015

also please use c++ casts and not old style c casts, see discussion #6791

@Montellese
Copy link
Member

@Tolriq: JSON-RPC doesn't allow calling the builtins directly and obviously it would be better to intergrate this into Player.Seek if it is added.

@xhaggi
Copy link
Member Author

xhaggi commented Mar 23, 2015

@Paxxi hope i'll have addressed all your comments. I've re-worked the whole method + make it thread-safe.
@FernetMenta added a cosmetic commit which breaks the statements to new line in Seek()

@xhaggi xhaggi force-pushed the builtin-seek-support branch 2 times, most recently from e100276 to 309aa6f Compare March 23, 2015 20:18
@Paxxi
Copy link
Member

Paxxi commented Mar 23, 2015

On ipad but looks good from what i see @xhaggi

@xhaggi
Copy link
Member Author

xhaggi commented Mar 23, 2015

@Montellese if we want to add this to Player.Seek (JSON-RPC) what do you think about if we differ between seconds and percent by adding a %-sign to the percent value?

@Tolriq
Copy link
Contributor

Tolriq commented Mar 24, 2015

@xhaggi this completely breaks the API without any backward compatibility.

@xhaggi
Copy link
Member Author

xhaggi commented Mar 24, 2015

@Tolriq better we leave everything as it is and use "10s" or "-7s" for seek by seconds?

@Tolriq
Copy link
Contributor

Tolriq commented Mar 24, 2015

Sounds better for compatibility and easy to use for remote makers.

But not sure about documentation for new comers, this make the value field quite complex in all it's states now.

@Montellese call but why not an string value like "relative" and a new parameter like "amount" ? Easy to follow and document and avoid mixing things when input is a string.

@xhaggi
Copy link
Member Author

xhaggi commented Mar 24, 2015

if we introduce new parameters we should use a separate one for each condition:

  • percent
  • seconds
  • step
  • time

This way we have backward compatibility and a clear set of parameters (self-explained)

@Tolriq
Copy link
Contributor

Tolriq commented Mar 24, 2015

Yes that's the idea :) Just need to keep compatibility too.

@da-anda
Copy link
Member

da-anda commented Mar 24, 2015

@xhaggi AFAIK you have to add the new JSON-RPC parameter to the schema description as well: https://github.com/xbmc/xbmc/blob/master/xbmc/interfaces/json-rpc/schema/methods.json#L284

and define a new type ofc: https://github.com/xbmc/xbmc/blob/master/xbmc/interfaces/json-rpc/schema/types.json#L175

@xhaggi
Copy link
Member Author

xhaggi commented Mar 24, 2015

@da-anda thanks for the hint, never touched that section ;). If fine by @Montellese I'll add this.

@NedScott
Copy link
Contributor

@Paxxi Actually, this feature has long since been requested on the forums, long before the current v15 seeking changes. This is one stone that kills many birds.

@Montellese
Copy link
Member

Checkout Montellese@4990799 as a replacement for your last commit. It adds explicitly named properties to the value parameter of Player.Seek like you mentioned above but also keeps the currently supported values. That way percentage, time and step can be used either as a pure value or as a named property and seconds is only supported as a named property.

This is completely runtime untested (only compile tested).

@xhaggi
Copy link
Member Author

xhaggi commented Mar 25, 2015

@Montellese great, i'll cherry-pick but couldn't test it by myself. @Tolriq if we provide a test-build could you do some tests?

@Tolriq
Copy link
Contributor

Tolriq commented Mar 25, 2015

I can easily test the no regressions and do quick test about new functions yes, and I promise I'll try to find time to build a VM to be able to build again :)

@Montellese
Copy link
Member

@Tolriq: I triggered a test build at http://jenkins.kodi.tv/job/WIN-32/4204/.

@xhaggi
Copy link
Member Author

xhaggi commented Mar 25, 2015

@Tolriq
Copy link
Contributor

Tolriq commented Apr 1, 2015

@xhaggi I had tested regression yesterday and there's things broken (like move to specific time) but had no time to make an investigation on what the problem is :(

Anyway here's the logs from Yatse :

As you can see hours / minutes are lost, seeking by percentage still work, and no time to test the new parameters.

JsonRpc.doRequest@243: Request : {"jsonrpc":"2.0","id":1,"method":"Player.Seek","params":{"playerid":1,"value":{"hours":1,"minutes":30,"seconds":49}}}
JSON TCP message : {"jsonrpc":"2.0","method":"Player.OnSeek","params":{"data":{"item":{"id":7,"type":"movie"},"player":{"playerid":1,"seekoffset":{"hours":0,"milliseconds":0,"minutes":0,"seconds":49},"speed":1,"time":{"hours":0,"milliseconds":103,"minutes":31,"seconds":38}}},"sender":"xbmc"}}

It seems I had an attak on my webserver so no time to do more until I fix it :(

@xhaggi
Copy link
Member Author

xhaggi commented Apr 1, 2015

@Tolriq thanks anyway 👍 will take a look at it

@xhaggi
Copy link
Member Author

xhaggi commented Apr 1, 2015

@Montellese after a quick look at your changes I don't think this is a newly introduced issue. Would be nice if you could take a look too.

@xhaggi
Copy link
Member Author

xhaggi commented Apr 3, 2015

@Montellese ping

@Montellese
Copy link
Member

Sorry I won't be able to look into it until Monday earliest.

@xhaggi
Copy link
Member Author

xhaggi commented Apr 7, 2015

okay, let me know what's wrong so i can fix it ;)

@xhaggi
Copy link
Member Author

xhaggi commented Apr 8, 2015

@Montellese don't forget to take a look ;)

@xhaggi
Copy link
Member Author

xhaggi commented Apr 9, 2015

@Montellese if you don't find time I'll drop your commit so this could be merged for BETA1.

@Montellese
Copy link
Member

@xhaggi: I should find time tomorrow evening. But feel free to drop my commit if you want to merge it ASAP.

@xhaggi
Copy link
Member Author

xhaggi commented Apr 9, 2015

i don't want to wait to long because i'm not sure when we close the merge window ;)

@Montellese
Copy link
Member

@xhaggi: Sorry for the delay. Please pick and squash Montellese@0d18c4d. There was a small mistake that broke time based seeking (and some bad formatting).

@xhaggi
Copy link
Member Author

xhaggi commented Apr 10, 2015

@Montellese thank you for the fix ;)

jenkins build this please

@xhaggi
Copy link
Member Author

xhaggi commented Apr 10, 2015

@Tolriq it would be really nice if you could test it again, if not no problem we'll merge it in and fix it later.

@xhaggi
Copy link
Member Author

xhaggi commented Apr 10, 2015

I've added a new commit which improves the "instant" seek support (if you disabled the seek delay).
As the seek is instantly processed we need to drop each call to Seek() during this process.

jenkins build this please

@da-anda
Copy link
Member

da-anda commented Apr 10, 2015

shouldn't the seek fix be a separate PR? ;)

@xhaggi
Copy link
Member Author

xhaggi commented Apr 10, 2015

mhhhh it does not really fix something it's more an improvement and I'm lazy ;)

@xhaggi
Copy link
Member Author

xhaggi commented Apr 10, 2015

@da-anda BTW instant seek is used by the seek built-in so it's related to this PR ;)

@xhaggi
Copy link
Member Author

xhaggi commented Apr 11, 2015

jenkins build and merge

@jenkins4kodi jenkins4kodi merged commit 7c04112 into xbmc:master Apr 11, 2015
@xhaggi xhaggi deleted the builtin-seek-support branch April 20, 2015 10:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Improvement non-breaking change which improves existing functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants