[Altix]

Maybe I'm missing the point of this, but imo the current skipping mechanism in XBMC is superior to Mediaportal's.

Thank you for the reply.

It's strange that the developers don't see the benefits of single button (right/left) fast forward/rewind in variable increments. Definitely a lot more convenient than having to bring the navigation menu up, selecting ff/rewind usually more than than say, +1h then +5m, +10s.

Here's to hoping someday they'll change their minds.

You don't have to bring up the navigation menu, you can already simply press left or right (repeatedly if desired) and the video will instantly skip forward or back along with the buttonpresses.

This is very fast and intuitive as compared to the Mediaportal way, where you first have to guess the amount you wanna skip forward, then press the correct amount of forwards according to that. Fast skipping forward while the video instantly updates is not possible as it "waits" until you are done pressing the desired number of skips.

What would be the advantage of this?

[bripeace]

Maybe I'm missing the point of this, but imo the current skipping mechanism in XBMC is superior to Mediaportal's.



You don't have to bring up the navigation menu, you can already simply press left or right (repeatedly if desired) and the video will instantly skip forward or back along with the buttonpresses.

This is very fast and intuitive as compared to the Mediaportal way, where you first have to guess the amount you wanna skip forward, then press the correct amount of forwards according to that. Fast skipping forward while the video instantly updates is not possible as it "waits" until you are done pressing the desired number of skips.

What would be the advantage of this?

The advantage is having more control over configuration. Since ultimately everything will be configurable you can have a seek which has a variable step size with a half second delay or on the other hand you can have a constant step size with no delay.

I can see the use of having a quarter second delay with a 30 second step size so i can hit the button 10 times to jump 5 minutes. I can also see the use of having one where if you hit the button 3 times it's jumping 5 minutes. There are a lot more possibilities when you consider this sort of setup. Not simply 30seconds/10 minutes forward/back and an additional 8 seconds back as it stands now.

[dteirney]

I've implemented a solution that seems to achieve the end goal of the Media Portal solution that works in with the XBMC configuration that already allows a short and large skip duration to be configured. Details in the trac ticket. If you are using the SVN version apply the patch, try it out and let me know how it can be improved.

http://trac.xbmc.org/ticket/9313

The following will not be implemented (by me at least):
* Any OSD delay that lets you choose the amount of time to skip forward by. If you know the time you want to get to, watch the time bar as you are seeking and press backwards one time after you have gone past that point. If you have a numeric keypad (I don't) then punch in the time.
* Any configurable list of timeouts to use when skipping forward. Most users won't do this. Multiplying the last time used by 2 is easy to explain and makes logic for going back to where you just were easier.

I haven't used Media Portal (no Windoze boxes here) but the delay that is introduced so you can change the seek duration on the OSD would just aggravate me. My long skip is set to the typical duration of commercial breaks. If I press the seek button I want it to seek immediately, not then ask me for how long I want to seek.

[dteirney]

I should check the forums before starting to code. I've attached what I think an appropriate solution is to make it faster to skip through a file given how XBMC currently behaves and what configuration options already exist for seeking.

Existing functionality for Edit Decision Lists, Commercial Breaks and Chapter Markers should all still work.

http://trac.xbmc.org/ticket/9313

[bripeace]

I've implemented a solution that seems to achieve the end goal of the Media Portal solution that works in with the XBMC configuration that already allows a short and large skip duration to be configured. Details in the trac ticket. If you are using the SVN version apply the patch, try it out and let me know how it can be improved.

http://trac.xbmc.org/ticket/9313

The following will not be implemented (by me at least):
* Any OSD delay that lets you choose the amount of time to skip forward by. If you know the time you want to get to, watch the time bar as you are seeking and press backwards one time after you have gone past that point. If you have a numeric keypad (I don't) then punch in the time.
* Any configurable list of timeouts to use when skipping forward. Most users won't do this. Multiplying the last time used by 2 is easy to explain and makes logic for going back to where you just were easier.

I haven't used Media Portal (no Windoze boxes here) but the delay that is introduced so you can change the seek duration on the OSD would just aggravate me. My long skip is set to the typical duration of commercial breaks. If I press the seek button I want it to seek immediately, not then ask me for how long I want to seek.

but why require xbmc to catch up to multiple skips which will take longer than just having something that has a very short delay (250-500ms) and can queue the seek while you pressing the button? Maybe it's the dueling solutions posted hours apart (one by me), but I see the benefit of both a user configurable dynamic step size and delay as a bit more robust than a simple algorithm.

Also any solution must have some sort of OSD component.

A further point: As I coded my approach I noticed (and as pointed out in the the other thread) the fact that the seek code could largely use an overhaul. Having so many disparate Seek and SeekTime functions are a bit redundant. A proper patch of this should probably simplify all of the seek code.

[dteirney]

but why require xbmc to catch up to multiple skips which will take longer than just having something that has a very short delay (250-500ms) and can queue the seek while you pressing the button? Maybe it's the dueling solutions posted hours apart (one by me), but I see the benefit of both a user configurable dynamic step size and delay as a bit more robust than a simple algorithm.

Also any solution must have some sort of OSD component.

A further point: As I coded my approach I noticed (and as pointed out in the the other thread) the fact that the seek code could largely use an overhaul. Having so many disparate Seek and SeekTime functions are a bit redundant. A proper patch of this should probably simplify all of the seek code.

Perhaps I totally don't understand what the value is of being able to define the skip duration is. For most of the files I play, the seeking is almost instant. I can see how the seeking queue might be problematic for files where seek performance is marginal, e.g. mpegts. Regardless though, typically when I'm seeking through a file I need the audio and video to determine if I'm at the right place. And the current patch will make even slow seek files easier to progress through since less queued seeks are needed to get further into the file. The current solution uses the existing OSD behavior. Whenever a seek is initiated the OSD (with playback time) is shown briefly.

I've coded up what works for me and will likely be useful to others who simply want to not have to press the seek button so many times.

At the end of the day this is a personal opinion. Media Portal users think that solution worked for some cases and XBMC users have said that the existing functionality is fine. My patch is not intended to replicate Media Portal functionality at all, just extend the XBMC functionality to not need as many button presses to surf quickly through a movie. For the amount of time I use seek and have been worried by what XBMC already provides I'm not sure why I even spent the time coding this up.

[zilexa]

I prefer the XBMC method...

[bripeace]

I added OSD stuff to my implementation, so it is now end user usable for the most part. I still feel the added configuration option is what makes this useful. Not the specific step sizes.

http://trac.xbmc.org/ticket/9312

[ubuntuf4n]

The XBMC skipping is good for me.

As a lot of other people, I'm using an optional software (IR Suite) for controlling XBMC.
The software allows different IR-Rates for while holding the button, that could be a little bit confusing because different users will use different IR-rates.

[0rca]

Can't wait to test this when I am back home. This wil be so great...

[JohnnyD2]

You don't have to bring up the navigation menu, you can already simply press left or right (repeatedly if desired) and the video will instantly skip forward or back along with the buttonpresses.

This is very fast and intuitive as compared to the Mediaportal way...

I'd have to fundamentally disagree.

There's 2 very significant counter-arguments.

1. Every DVD player produced since the dawn of man operates multi-step FF\RW.

2. Most consumer Tivo-esque boxes (Sky+ in the UK) operate multi-step FF\RW in exactly the same way, just with different time-steps.

The problem is the Dev's seem to have confused what it means to be intuitive.
Intuitiveness is not necessarily 'what comes naturally' but is achieved through a combination of 3 things:
1. Familiarity
2. What is explained as you go (aka Feedback)
3. What comes naturally

...in that order.

Taking this into account, it means the multi-step FF\RW is ingrained into the consciousness of practically any individual who's familiar with either. Thanks to 1. that's a helluva big user base.

To give an example of 2. - if you have a system which says 'Press 1 for X, press 2 for Y' you know where you are. It's inherently intuitive. Yet without the explanation it would be the most obtuse system known to man. I.e. feedback is crucial.

(...which brings me onto a side point, feedback in XBMC could be vastly improved. I'm experienced in linux\unix and mediaportal, yet I couldn't for the life of me figure out how to add my movies to XBMC. Movies told me to go to videos (why?? why can't I do it in Movies?) and videos had no option to 'add library source folder'. I tried the side menu, nothing. Right-clicking, nothing. Settings, nothing. I had to read the forums before I found what should be the right-click menu is actually brought up by using 'c'. Why? Everyone is familiar with right-click. Legacy from XBOX implementation it may be, but as soon as it was ported, why not assign both 'c' and right-click to the context menu? And you might say 'why didn't you read the manual?' Well, if I have to do that then it's not intuitive, is it.....)

Back on topic, the only complaint I have with both the DVD\Sky+ systems is: they don't go fast enough. Example: On Sky I want to skip the adverts. 30x speed is 4 FF clicks, and still takes 6 seconds to skip through 5 minutes of them. In Mediaportal there's an option to skip 3 minutes or 5 minutes (which I can configure to be the 1st, or the 5th click). Using that I skip the adverts instantaneously. I might overshoot by 10seconds or so, but that's an acceptable hit - I usually overshoot at 30x speed anyway! As a result it's actually quicker and more accurate by using the mediaportal method.
Using the XBMC method I don't actually know what time it uses for big\small steps. I'm looking now - I can't find a definitive answer even on the wiki. This means that it's extremely unintuitive - I don't know what's skipping how far, there's no visual feedback, I have to apply scientific analysis to it to figure it out. Hardly consumer-level satisfaction. Having said that, assuming big skips are 30seconds (that's not 'big') I have press it 10 times to skip 5 minutes of adverts. Not only that but with 10 keypresses I'm liable to mis-count. Which means that we're back to the overshoot situation, AND I'm more frustrated because I've had to advance the video myself, instead of the UI doing the work for me.

Lastly the configurability of Mediaportal's method is crucial to user satisfaction. It means that if I want 15 FF steps (all the way to 3hrs) I can. If I want 4, which tops out at 15 minutes, I can. It's customizable to me. And because of that's it's an immensely satisfying system.

Hmm. Massively didn't mean this turn into a big old critique, I'm new to XBMC and I actually think the Devs are doing a sterling job.

As such I don't know the technical reasons why some of the functionality is as it is - there may be restrictions I don't know about. However, with all other things being equal, I believe their definition of 'intuitive' has been affected because they may have become too close to XBMC and so what's familiar (and therefore intuitive) to them has led to losing sight of what's familiar to everyone else...

Lastly I sincerely hope this post will be taken in the spirit it's meant - an open and honest consumer-level perspective.

Thanks for reading...

[jmarshall]

Thanks for your comments - I suggest you take your comments regarding the context menu to another thread - no point taking this one off topic.

I think it's definitely worth standing back and trying to see the bigger picture of what seeking is used for without focusing on the specifics of how it works - once we have the end goal, we can critique possible implementations.

I have a feeling that really there's 2 separate seeking behaviours wanted:

1. Advert jumping, where you typically jump a set amount, with some fine tuning back and forth for over or under jumps.

2. Searching for a particular scene in the video, where it's no set amount - you're instead searching for something based on visual or audio cues in the content itself. FFWD/REWD can work well for this sometimes, but FFWD and REWD don't work well on many compressed media formats, but there may be some combination of jumping through the media that might also work.

For number 2, there's the issue of how long each seek should be, which depends on the type of media you're playing: If you have a music video you don't want to jump 5 minutes in one go. If you have a movie, you might want to jump 10 minutes in one go, or jump chapter to chapter if that information is available. Should these be on the same button?

The "advert skipping" thing is quite specific, and for those that watch a lot of prerecorded TV with ads, I can very much see the advantage of it. I'm not sure it fits in well with a more generic seek behaviour though?

Cheers,
Jonathan

[vinistois]

I have to say I think its perfect just the way it is.

hit right to go fwd, hit left to go back, hit up to go fwd alot, down to go back alot. What could be simpler?

[waldo22]

I have a feeling that really there's 2 separate seeking behaviours wanted:

Jonathan

3) your 11-month-old is making a lot of noise, or you just got through a really loud explosion scene (see DRC thread), or someone is speaking in an accent that you aren't used to...

"What the &%* did he just say?"

-> skip 10 sec. backwards.



Also, I think skipping to chapter markers when available is the desired behavior for the >>| and |<< buttons. They can fall back to be the same as left and right if no chapter info is available, or they could be "big skip" while left and right are "small skip", or vice-versa.

[dteirney]

I use XBMC to predominantly play pre-recorded TV through MythTV, but I also watch a lot of Movies.

To cater for pre-recorded TV Shows I have the following setup:
1) Big Skip Forward = 210 seconds (7 * 30 second commercial breaks)
2) Small Skip Forward = 30 seconds (1 commercial break)
3) Small Skip Backward = 10 seconds (to cater for slight overshoot and "what did they say" moments)
4) Big Skip Backward = 210 seconds (back to start of commercial break - mainly to match the skip forward size).

I've found this to work well. Of course, when MythTV has commercial flagged well it's even easier

For playback of any other sort of content, I've only needed to skip forward lots if the resume position gets lost for some reason. Typically then I'm skipping based on what I remember of the show so need the audio / visual feedback.

I also use a WiiRemote so FF and RW are difficult to initiate and in general I've found to be less than average in terms of feedback with mpegts files. As Jonathan mentioned, rewind for compressed video codecs designed to only play forward is extremely hit and miss. Fast forward and rewind were the only options that were technically possible with tape driven media such as VHS...

I think XBMC could benefit from having the small and large skip durations configurable in the UI rather than just through advanced settings. This would go some way to address the "I don't actually know what time it uses for big\small steps" issue. Some sensible fixed increments could be coded for the UI and advanced settings (http://wiki.xbmc.org/?title=Advancedsett...3Cvideo.3E) could still be used for weird combinations (like my 210 seconds example).

Perhaps the settings would be accessed through "System" > "Video" > "Playback" or a new "System" > "Video" > "Skipping" category. Perhaps:
Small = 10, 30, 60, 90, 120, 180 (seconds)
Big = 2, 3, 5, 10, 15, 20, 30 (minutes)
Perhaps also an option to cater for the "I want to go back to listen to what they just said again" use case, e.g. 10 seconds for small skip backward.