Well i’ll be a monkey’s uncle… it works! even multiple presses seem to work fine!
Does your remote have a sticker/marking on the back that has RC6 on it? Have you customized the keymap?
Yes, it says RC 6. No, i have not been successful at remapping the keys
So are you saying that the arrow keys do work the skip steps now?
Yes, sorry i wasn’t clear earlier. Here’s a recap:
- Fast Fwd/Rewind buttons do what they are supposed to do.
- Skip Fwd/Back buttons do NOT do what they are supposed to do, niether does using the mouse and clicking the skip “buttons” on the bottom of the screen.
- The Left/Right buttons (the two of four that surround the green button on the remote) do the function of skip fwd/back respectively.
So, it seems that it is a mapping issue on the remote. But, why the bad behavior when using the mouse to click the screen buttons??? This is a mystery, but one i care not to concern myself with at this point.
It’s working as intended, I believe the skip fwd/back buttons are chapter skips which will skip to the end of a video without chapters.
You mean the buttons like this
|<< >>|
These should operate like track skip. If the file is separated into seperate tracks (like a DVD may be seperated into scenes) these buttons would skip between them. But when a file contains no such separations, it will only skip to the end of the file.
Edit: chapters as dilligaf says! ;). Tracks when related to music.
@ActionA and @Dilligaf , thanks for the clarifications. So the Kodi behavior doesn’t match that of Win MC. Makes perfect sense now. Thanks for all the help… been living with this for over 2 years now (basically since OSMC day 1).
Yes, those are the buttons that i had expected to envoke the skip function. Those are the buttons that i used to use with Win MC for the same function. However, give your description of how these buttons work, i’m not sure that Win MC had a similar function. I like the extra functionality… just didn’t know how to use it.
Well, all was good until the latest round of updates… Now the < and > (to the left and right of the ‘OK’ button) no longer invoke the skip function, or at least as they should. The > button seems to skip back while i’m not sure exactly what the < button does as i lost my buffer (pause of Live TV). I’m buffering now to see what happens.
I double checked the skip settings and they are what i expect. Any ideas why this behavior has changed in this latest release?
EDIT: well, after entering the setup and simply looking at the settings (didn’t change any of them), things seem to be working ok now.
EDIT^2: well, i give up… i can’t even describe the behavior. one > push and it fastforwards 10 sec. two > presses (inside the delay setting of 750ms) and it jumps back 10 sec, even though it says +00:10 in the lower right hand corner. Then, when the video does start playing again, it’s “choppy” like it’s dropping frames. Pausing of Live TV is “at your own risk” at this point.
Seems to work here. Does skip work when playing a recording vs a live tv stream? Do you have custom buffer/cache settings in advancedsettings.xml ? There are cache settings changes in Krypton, see http://kodi.wiki/view/HOW-TO:Modify_the_cache#Kodi_v17_changes and http://kodi.wiki/view/Advancedsettings.xml#cache If the postings in the Wiki represent the “default” settings as they commonly do then the default cache method has been changed to 0 which caches to hard disk/sd card which is not good sensible defaults for the Pi would be something like
<cache>
<memorysize>20971520</memorysize>
<buffermode>1</buffermode>
<readfactor>10.0</readfactor>
</cache>
Discourse is not behaving and mangling my xml example, here it is on paste.osmc.io
http://paste.osmc.io/oyipefokel.xml
Note that they are now in cache tags rather than network and the setting names are changed from earlier OSMC versions
EDIT: I know I went off on a tangent but my point is if the stream from PVR is not caching then skip will never work
ok, my advancedsettings.xml file looks like a traditional xml file and i’m assuming you just left all the “fluff” out of your post. Following that same pattern, my settings are
540
720
false
1
30
My backend server has the recording/buffering location set as a networked location. Are you saying that Kodi might be overriding that settings for buffering of Live TV?
Edit: by the way, with the rate at which updates come out, is there a way that the old settings can be retained during an update? My Live TV went away with one of the latest updates and i had to reenable the client. My wife was without TV until i could get home and figure out what was going on.
As stated, Discourse (this forum) mangled my paste so I put the details on paste.osmc.io but looking at the values you posted I think they come from the “system” advancedsettings. I am referring to the “userdata” advancedsettings.xml located in /home/.kodi/userdata which will not be there unless you create it. The links I posted explain the format.
Anyways the question remains, do skip steps work on a recorded video? Is it a live tv only problem? Do you have an advancedsettings.xml in your userdata directory? A debug log capturing the problem may help. Without seeing a debug log I’m only guessing at a buffer problem.
@Dilligaf sorry for the confusion. The settings i displayed were from the /usr/share/kodi/system/advancedsettings.xml
The /home/osmc/.kodi/userdata has no advancedsettings.xml. So i’ll follow the links you posted and create one.
Recorded video (a ripped movie) works just fine (and no worries… i own the movie, no pirating here). Prerecorded TV works fine too. I will say that i’m using a network tuner (HDHomeRun EXTEND) and the reception in my area isn’t that great. So there are sometimes some dead spots in the video stream. Win Media Center handled this “OK”, but i have noticed Kodi/TVHeadend doesn’t handle this very well. After playing around with it more last night, if i was in a part of the video that had no tiling (indicative of intermittent reception issues) the skip would work just fine. But, if the skip tried to skip over a messed up part of the video, sometimes a skip forward would back all the way up to the beginning of the recording. Just plain weird behavior. Nonetheless, it appears to be related to a “break” in the video stream.