[fixed] BassPlayer bug (1 Viewer)

[l337]

then why do I need so much buffer when it is no forward / back coil is possible, and yes of course I need something that could have the first cassette recorder 20 years ago "incredible here"
what is the default value of the buffer?

 

[hwahrmann]

IT WORKS.

Several users, including the thread starter, have confirmed that using the right buffer size the problem is gone. So what?

I cannot do anything against too high buffer usage.
And there are other ways to circumvent that.

How often do you do a FF / REW?
I am mainly using MP for music only and NEVER do FF / REW.

And if i would do it, i would use skip steps.

The only way to get around that is to remove the ability to set the buffer in Config and let MP set it the way it works.
And i am sure that some other people will then start a similar thread to demand back the buffer settings.

 

[jameson_uk]

This is a valid workaround... but if the FF/RW option is available people will attempt to use it, and IMO it should "just work".

Agreed, this should just work. If we have issues that require tinkering we would make skip steps the default behavior and have a wiki article about ffwd/rew.

I am still not 100% clear what the issue is. If you have 2s of audio in the buffer and press ffwd to go to 2x are we saying that the point it wants to jump to is already in the buffer so it goes there then the next jump is not in the buffer and it somehow jumps back to the original point? Is the buffer kept filled when playing at faster speeds or if we need to get to a point after the buffer does it then jump to the right point kind of like skip steps?

 

[mm1352000]

IT WORKS.



Several users, including the thread starter, have confirmed that using the right buffer size the problem is gone. So what?

Yep, I understand that.
The answer to "so what" is that FF/RW doesn't work out-of-the-box with BASS - that is the issue from my perspective.
In other words, I think we need to do something to fix the out-of box experience. For example, changing the default buffer setting and documentation/warning in the wiki for people that decide to change the buffer setting.

People expect MP to "just work", and there is little patience when it doesn't. Most people don't know, understand or care about why something like this doesn't work. They'll think "stupid MP doesn't work properly" and use it as one more excuse to switch to other software.

I cannot do anything against too high buffer usage.

Okay... but why is the default buffer value set in such a way as to make FF/RW not work? That seems wrong to me.
Wiki says:

Buffering is the amount of seconds MediaPortal reads ahead to avoid stuttering. Change if you experience any stuttering.

Natural inclination with sliders for such a setting is to think "more is better"... but actually, we see here that is not actually the case.
The wiki says why the setting is available, but it doesn't warn about the consequences of increasing the setting to max. That also seems wrong to me.

How often do you do a FF / REW?

I don't use music in MP. I use Winamp because I find the ability to search and shuffle better.
I don't use FF/RW with Winamp - I drag the slider to the position that I want.
...but that is beside the point!
If we offer the feature, it should work... or we should have a clear explanation why it doesn't work.

I am mainly using MP for music only and NEVER do FF / REW.

And if i would do it, i would use skip steps.

Fair enough, but other people are free to use it because it is there... and for them it should work. Not everyone is the same.

The only way to get around that is to remove the ability to set the buffer in Config and let MP set it the way it works.

And i am sure that some other people will then start a similar thread to demand back the buffer settings.

Okay, we can't remove the setting then. No problem... but can we fix the default value and add some comments in the wiki?

 

[jameson_uk]

The answer to "so what" is that FF/RW doesn't work out-of-the-box with BASS - that is the issue from my perspective.
In other words, I think we need to do something to fix the out-of box experience. For example, changing the default buffer setting and documentation/warning in the wiki for people that decide to change the buffer setting.

People expect MP to "just work", and there is little patience when it doesn't. Most people don't know, understand or care about why something like this doesn't work. They'll think "stupid MP doesn't work properly" and use it as one more excuse to switch to other software.

As above this is exactly why this should work out the box (even if that out the box solution was skip steps)

T

I cannot do anything against too high buffer usage.

Okay... but why is the default buffer value set in such a way as to make FF/RW not work? That seems wrong to me.
Wiki says:

Buffering is the amount of seconds MediaPortal reads ahead to avoid stuttering. Change if you experience any stuttering.

Natural inclination with sliders for such a setting is to think "more is better"... but actually, we see here that is not actually the case.
The wiki says why the setting is available, but it doesn't warn about the consequences of increasing the setting to max. That also seems wrong to me.

I started looking at this but I am confused as to what is actually happening here. If I press ffwd when playing (even at say x4 or x8) then time actually goes forward in real time but the audio is played at the speed expected and then the clock jumps backwards.
I will post a video as my explanation is terrible

What I don't get is why this is happening. Are we saying that it is speeding up playback but only of what is already in the buffer? If there was no enough data getting through I could see it stuttering but the fact it jumps back in time has me very confused...
@hwahrmann can you explain what the issue is with the buffer

 

[hwahrmann]

There seems to be an issue when we jump to a position, which is already in the buffer.
we seek 80ms * speed.
there seems to be no issue when the speed is 8 or higher, but for lower speeds there seems to be a loop.

This was introduced instead of the skip steps in 1.2.
Then the users were crying to get skip steps back.
Now they are back and i think we should use it.

 

[hwahrmann]

ok. i've found a way to make it work with even 2 seconds of buffer.

Mantis 4446.
Branch created and code is in Git.
please test http://mantis.team-mediaportal.com/view.php?id=4466

 

[jameson_uk]

ok. i've found a way to make it work with even 2 seconds of buffer.

Mantis 4446.
Branch created and code is in Git.
please test

Seems to work great for FFWD but not for REW at slower speeds.
It is as if the stream is still moving on so when you REW at low speed you are skipping back at the same speed as the stream is moving on so you get stuck at the same point

 

[Sebastiii]

ok. i've found a way to make it work with even 2 seconds of buffer.

Mantis 4446.
Branch created and code is in Git.
please test

Seems to work great for FFWD but not for REW at slower speeds.
It is as if the stream is still moving on so when you REW at low speed you are skipping back at the same speed as the stream is moving on so you get stuck at the same point

I confirm REW seems to not work (and do a like a refresh screen)

 

[hwahrmann]

Seems to work great for FFWD but not for REW at slower speeds. It is as if the stream is still moving on so when you REW at low speed you are skipping back at the same speed as the stream is moving on so you get stuck at the same point

of course you will get some troubles on REW.
Since at lower speeds, we only jump back 80ms * _speed

so for double rewind it is only 160ms and the stream continues immediately to play from this position.

If you ask me, i would get rid of this crap and use skip steps only.
I can#t see any reason, why we would need this.