-
-
Notifications
You must be signed in to change notification settings - Fork 6.3k
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
Conversation
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.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
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) |
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.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
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.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
also please use c++ casts and not old style c casts, see discussion #6791 |
06d17e9
to
d1346d3
Compare
@Tolriq: JSON-RPC doesn't allow calling the builtins directly and obviously it would be better to intergrate this into |
@Paxxi hope i'll have addressed all your comments. I've re-worked the whole method + make it thread-safe. |
e100276
to
309aa6f
Compare
On ipad but looks good from what i see @xhaggi |
@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? |
@xhaggi this completely breaks the API without any backward compatibility. |
@Tolriq better we leave everything as it is and use "10s" or "-7s" for seek by seconds? |
5c2f641
to
cb27acc
Compare
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. |
if we introduce new parameters we should use a separate one for each condition:
This way we have backward compatibility and a clear set of parameters (self-explained) |
Yes that's the idea :) Just need to keep compatibility too. |
@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 |
@da-anda thanks for the hint, never touched that section ;). If fine by @Montellese I'll add this. |
@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. |
Checkout Montellese@4990799 as a replacement for your last commit. It adds explicitly named properties to the This is completely runtime untested (only compile tested). |
@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? |
cb27acc
to
3f8a5c1
Compare
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 :) |
@Tolriq: I triggered a test build at http://jenkins.kodi.tv/job/WIN-32/4204/. |
@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}}} It seems I had an attak on my webserver so no time to do more until I fix it :( |
@Tolriq thanks anyway 👍 will take a look at it |
@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. |
@Montellese ping |
Sorry I won't be able to look into it until Monday earliest. |
okay, let me know what's wrong so i can fix it ;) |
@Montellese don't forget to take a look ;) |
0ce3e89
to
1a25691
Compare
@Montellese if you don't find time I'll drop your commit so this could be merged for BETA1. |
@xhaggi: I should find time tomorrow evening. But feel free to drop my commit if you want to merge it ASAP. |
i don't want to wait to long because i'm not sure when we close the merge window ;) |
@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). |
…eeking by a number of seconds
1a25691
to
3fd4e1a
Compare
@Montellese thank you for the fix ;) jenkins build this please |
@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. |
I've added a new commit which improves the "instant" seek support (if you disabled the seek delay). jenkins build this please |
shouldn't the seek fix be a separate PR? ;) |
mhhhh it does not really fix something it's more an improvement and I'm lazy ;) |
@da-anda BTW instant seek is used by the seek built-in so it's related to this PR ;) |
64c51c2
to
a69dde3
Compare
jenkins build and merge |
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 ;)Related discussion at http://forum.kodi.tv/showthread.php?tid=217616&pid=1957016#pid1957016