broadcasting disconnects

[Darren Smithson]

Ok guys, we've been using Mv2 extensively now for several months and there are two serious issues that need fixing urgently.

1. Memory cache issue. If you play a long track- for example a 90 minute radio play- (or several long tracks) and then attempt to load another, Mixxx simply stops broadcasting. Sometimes it doesn't TELL you it has, but mostly it just locks. It will also eventually just lock or throw off stream after several days of playing even if there have been no long tracks.

2. Any weakness in internet connection causes it to disconnect stream- even a nano second of fluctuation. For example, if I am broadcasting at 5pm and my neighbours get home and start to check their emails etc, there is a momentary drop in MY bandwidth as supplied by the ISP. This causes Mixxx to drop the stream. Every time.

Note- we are 4 users all living in different areas, all on different ISPs, all on different computers. The only common ground is Windows 10.

We LOVE Mv2 but the caching and robustness really needs sorting out urgently as we may be forced to replace it at our station (we would make a fab case study for you if you can make it work!).

[Daniel Schürmann (daschuer)]

What is Mv2?

Which version of Mixxx are you using? 64 or 32 bit?

What means "just lock"? What does Mixxx and what not. Are the decks working, does the GUI respond?

"This causes Mixxx to drop the stream" What does Mixxx do when it drops the stream?
What does the server do?

I have prepared a Alpha version, that writes a lot more diagnostic infos into the mixxx.log file.
http://downloads.mixxx.org/builds/master/release/

Some of the known broadcasting issues are already solved, but be warned, it contains a lot of other untested changes.

Please try out if your issues are solved. If not, provide a mixxx.log of a faulty run.
You will find it at %APPDATA%\Mixxx\mixxx.log

[Sam (vhexs)]

I assume "Mv2" is Mixxx version 2.

[Darren Smithson (darrenitu)]

Hi Daniel

It's Mixxx V2.0 64bit. We've been testing the alpha version extensively and
the cache overflow issue still remains, though I personally feel it IS
better than before.

What happens:

1. Normal size songs will play on autoplay for a day or two but then Mixxx
crashes- ie it simply stops (not the alpha), or it disconnects the stream.
The Alpha version will try to reconnect but fails to do so, informing us of
both the disconnect and the attempted reconnect. However, once you try to
manually reconnect, it will tick the Enable Live button, but actually it is
NOT connected unless you shut Mixxx down and reboot it. (this is true of V2
and the alpha)

2. Long tracks, such as a 90 minute drama or a replay of one of our live
shows (usually about 3hours) can cause all versions of mixxx to simply stop
loading, or disconnect. I found the Alpha version a little better as it
happens though! However what I said in 1 above is true here also.

NOTE: when Mixxx disconnects, the boradcast server is still up. We also
tried the alpha on a server from a completely different company (Radio
Stream as opposed to L2MR) and it still did 2 above.

Hope this helps! Looking forward to a beta :)

Darren

On 14 September 2016 at 20:23, Daniel Schürmann <email address hidden>
wrote:

> What is Mv2?
>
> Which version of Mixxx are you using? 64 or 32 bit?
>
> What means "just lock"? What does Mixxx and what not. Are the decks
> working, does the GUI respond?
>
> "This causes Mixxx to drop the stream" What does Mixxx do when it drops
> the stream?
> What does the server do?
>
> I have prepared a Alpha version, that writes a lot more diagnostic infos
> into the mixxx.log file.
> http://downloads.mixxx.org/builds/master/release/
>
> Some of the known broadcasting issues are already solved, but be warned,
> it contains a lot of other untested changes.
>
> Please try out if your issues are solved. If not, provide a mixxx.log of a
> faulty run.
> You will find it at %APPDATA%\Mixxx\mixxx.log
>
> ** Changed in: mixxx
> Status: New => Confirmed
>
> ** Changed in: mixxx
> Importance: Undecided => High
>
> ** Changed in: mixxx
> Milestone: None => 2.1.0
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1623620
>
> Title:
> TWO SERIOUS BUGS in Mv2 (cache management maybe?)
>
> Status in Mixxx:
> Confirmed
>
> Bug description:
> Ok guys, we've been using Mv2 extensively now for several months and
> there are two serious issues that need fixing urgently.
>
> 1. Memory cache issue. If you play a long track- for example a 90
> minute radio play- (or several long tracks) and then attempt to load
> another, Mixxx simply stops broadcasting. Sometimes it doesn't TELL
> you it has, but mostly it just locks. It will also eventually just
> lock or throw off stream after several days of playing even if there
> have been no long tracks.
>
> 2. Any weakness in internet connection causes it to disconnect stream-
> even a nano second of fluctuation. For example, if I am broadcasting
> at 5pm and my neighbours get home and start to check their emails etc,
> there is a momen...

[Daniel Schürmann (daschuer)]

Do you have the mixxx.log file from an alpha run for me?
You will find it at %APPDATA%\Mixxx\mixxx.log
It is probably still there with a number suffix

1. OK, the diconnect issue itselves is still there :-/ I am curious to read the mixxx.log.

The "not reconnect, only after restart" is an known issue tracked here:
https://bugs.launchpad.net/mixxx/+bug/1532461

2. What means "stop loading". Does the deck continue to play the track though the sound-card?
Are other decks still reacting on play/pause?

A mixxx log from a run showing 2. would be also nice.

[Darren Smithson (darrenitu)]

No worries will attach the log when I land, in the meantime to clarify what I mean by stop loading... I mean that the next song up simply refuses to load onto the deck. This is not very common, mostly it's the disconnecting issue. Give me til this evening and I will forward the log.

Sent from my iPhone

> On 8 Nov 2016, at 14:26, Daniel Schürmann <email address hidden> wrote:
>
> Do you have the mixxx.log file from an alpha run for me?
> You will find it at %APPDATA%\Mixxx\mixxx.log
> It is probably still there with a number suffix
>
> 1. OK, the diconnect issue itselves is still there :-/ I am curious to
> read the mixxx.log.
>
> The "not reconnect, only after restart" is an known issue tracked here:
> https://bugs.launchpad.net/mixxx/+bug/1532461
>
> 2. What means "stop loading". Does the deck continue to play the track though the sound-card?
> Are other decks still reacting on play/pause?
>
> A mixxx log from a run showing 2. would be also nice.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1623620
>
> Title:
> TWO SERIOUS BUGS in Mv2 (cache management maybe?)
>
> Status in Mixxx:
> Confirmed
>
> Bug description:
> Ok guys, we've been using Mv2 extensively now for several months and
> there are two serious issues that need fixing urgently.
>
> 1. Memory cache issue. If you play a long track- for example a 90
> minute radio play- (or several long tracks) and then attempt to load
> another, Mixxx simply stops broadcasting. Sometimes it doesn't TELL
> you it has, but mostly it just locks. It will also eventually just
> lock or throw off stream after several days of playing even if there
> have been no long tracks.
>
> 2. Any weakness in internet connection causes it to disconnect stream-
> even a nano second of fluctuation. For example, if I am broadcasting
> at 5pm and my neighbours get home and start to check their emails etc,
> there is a momentary drop in MY bandwidth as supplied by the ISP. This
> causes Mixxx to drop the stream. Every time.
>
> Note- we are 4 users all living in different areas, all on different
> ISPs, all on different computers. The only common ground is Windows
> 10.
>
> We LOVE Mv2 but the caching and robustness really needs sorting out
> urgently as we may be forced to replace it at our station (we would
> make a fab case study for you if you can make it work!).
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1623620/+subscriptions

[Darren Smithson (darrenitu)]

Here are what I think are the log files from Mv2Alpha testing on the
Thursday and Friday :)

On 8 November 2016 at 16:48, Darren Smithson <email address hidden> wrote:

> No worries will attach the log when I land, in the meantime to clarify
> what I mean by stop loading... I mean that the next song up simply refuses
> to load onto the deck. This is not very common, mostly it's the
> disconnecting issue. Give me til this evening and I will forward the log.
>
> Sent from my iPhone
>
> > On 8 Nov 2016, at 14:26, Daniel Schürmann <email address hidden>
> wrote:
> >
> > Do you have the mixxx.log file from an alpha run for me?
> > You will find it at %APPDATA%\Mixxx\mixxx.log
> > It is probably still there with a number suffix
> >
> > 1. OK, the diconnect issue itselves is still there :-/ I am curious to
> > read the mixxx.log.
> >
> > The "not reconnect, only after restart" is an known issue tracked here:
> > https://bugs.launchpad.net/mixxx/+bug/1532461
> >
> > 2. What means "stop loading". Does the deck continue to play the track
> though the sound-card?
> > Are other decks still reacting on play/pause?
> >
> > A mixxx log from a run showing 2. would be also nice.
> >
> > --
> > You received this bug notification because you are subscribed to the bug
> > report.
> > https://bugs.launchpad.net/bugs/1623620
> >
> > Title:
> > TWO SERIOUS BUGS in Mv2 (cache management maybe?)
> >
> > Status in Mixxx:
> > Confirmed
> >
> > Bug description:
> > Ok guys, we've been using Mv2 extensively now for several months and
> > there are two serious issues that need fixing urgently.
> >
> > 1. Memory cache issue. If you play a long track- for example a 90
> > minute radio play- (or several long tracks) and then attempt to load
> > another, Mixxx simply stops broadcasting. Sometimes it doesn't TELL
> > you it has, but mostly it just locks. It will also eventually just
> > lock or throw off stream after several days of playing even if there
> > have been no long tracks.
> >
> > 2. Any weakness in internet connection causes it to disconnect stream-
> > even a nano second of fluctuation. For example, if I am broadcasting
> > at 5pm and my neighbours get home and start to check their emails etc,
> > there is a momentary drop in MY bandwidth as supplied by the ISP. This
> > causes Mixxx to drop the stream. Every time.
> >
> > Note- we are 4 users all living in different areas, all on different
> > ISPs, all on different computers. The only common ground is Windows
> > 10.
> >
> > We LOVE Mv2 but the caching and robustness really needs sorting out
> > urgently as we may be forced to replace it at our station (we would
> > make a fab case study for you if you can make it work!).
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/mixxx/+bug/1623620/+subscriptions
>

[Daniel Schürmann (daschuer)]

Analysis:

mixxx.log.4:
* The ~10 s Network cache is filled up, because the stream doe not reach the server
* reaches the limit and disconnects.
* The following retry fails with socket error -4
This happens when the server can be reached but the socket connection cannot be established for any reason.

mixxx.log.5 a:
* The 743 ms m_pOutputFifo is filled up. Which is used to sync the network stream clock with the soundcard clock.
* Even though the buffer is full the broadcast thread is not scheduled for 6 audio callback cycles.

mixxx.log.5 b:
* The 743 ms m_pOutputFifo is filled up again.
* This time the broadcast thread is scheduled but stalled encoding the stream.

mixxx.log.5 c:
* The 743 ms m_pOutputFifo is filled up again.
* This time the broadcast thread is scheduled but updating metadata.

mixxx.log.6:
* first attempt to connect results in "Socket is busy"
* After connect, we receive a "Socket error"
* Reconnection fails.

mixxx.log.7:
Is similar to mixxx.log.4

[Daniel Schürmann (daschuer)]

Log 4 and 7 are looking like network performance issues where Mixxx is not able to recover gracefully.

Could it be a temporary bandwidth decrease or is it a Mixxx / Windows / Hardware issue.

Maybe the disconnect messages are queued in the buffer next to the following connection attempt. This might fail because the server is still shutting down ...

Log 5 looks as a CPU overload issue.

Which AudioBuffer size do you use in the Hardware preferences? Could it be caused by an other Windows app like Virus-Scanner o

[Darren Smithson (darrenitu)]

Hiya

We use 4 different computers on 3 different isps and from 4 different locations, but we all have the same disconnect issues. We also have a checklist we go through before each show, one of which is to turn off anti virus etc. We also switch off lots of other background resources e.g. iPod helper etc. We have also tested on 2 different radio hosts and had the same disconnect.

Sent from my iPhone

> On 8 Nov 2016, at 22:40, Daniel Schürmann <email address hidden> wrote:
>
> Log 4 and 7 are looking like network performance issues where Mixxx is
> not able to recover gracefully.
>
> Could it be a temporary bandwidth decrease or is it a Mixxx / Windows /
> Hardware issue.
>
> Maybe the disconnect messages are queued in the buffer next to the
> following connection attempt. This might fail because the server is
> still shutting down ...
>
>
> Log 5 looks as a CPU overload issue.
>
> Which AudioBuffer size do you use in the Hardware preferences? Could it
> be caused by an other Windows app like Virus-Scanner o
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1623620
>
> Title:
> TWO SERIOUS BUGS in Mv2 (cache management maybe?)
>
> Status in Mixxx:
> Confirmed
>
> Bug description:
> Ok guys, we've been using Mv2 extensively now for several months and
> there are two serious issues that need fixing urgently.
>
> 1. Memory cache issue. If you play a long track- for example a 90
> minute radio play- (or several long tracks) and then attempt to load
> another, Mixxx simply stops broadcasting. Sometimes it doesn't TELL
> you it has, but mostly it just locks. It will also eventually just
> lock or throw off stream after several days of playing even if there
> have been no long tracks.
>
> 2. Any weakness in internet connection causes it to disconnect stream-
> even a nano second of fluctuation. For example, if I am broadcasting
> at 5pm and my neighbours get home and start to check their emails etc,
> there is a momentary drop in MY bandwidth as supplied by the ISP. This
> causes Mixxx to drop the stream. Every time.
>
> Note- we are 4 users all living in different areas, all on different
> ISPs, all on different computers. The only common ground is Windows
> 10.
>
> We LOVE Mv2 but the caching and robustness really needs sorting out
> urgently as we may be forced to replace it at our station (we would
> make a fab case study for you if you can make it work!).
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1623620/+subscriptions

[Daniel Schürmann (daschuer)]

OK, so we can sort out the ISP and other Applications.

It looks like Mixxx itself is not able to empty the network buffer in time. However the issue starts slowly and Mixxx is always able to pass some samples to the network (see attached graph).
So it is not a deadlock. It is more a "slow down issue".

What is your buffer size in hardware preferences? Does your under-run counter at the bottom of the hardware preferences count?

###

The "stop loading" issue is tracked here https://bugs.launchpad.net/mixxx/+bug/1525738

Since we have actually fixed one deadlock issue since 2.0: https://bugs.launchpad.net/mixxx/+bug/1565382 it is very important for us to know, if it ever happens with Mixxx 2.1 alpha, that a single deck just refused to load a track. Are you able to confirm this?
If you manage to reproduce it with Mixxx 2.1 alpha a mixxx.log would be very helpful.

This bug might be also related to https://bugs.launchpad.net/mixxx/+bug/1445298

[Darren Smithson (darrenitu)]

Hi Daniel, I am unsure what you mean by the buffer in hardware preferences?
Do you mean preferences in Mixxx or in Windows? Under Mixxx it is set to
92.2ms? I have attached an image of my settings (Mv2.0)- which is the same
for all our Mixxx setups and one of the underflow counter you refer to
(also from 2.0).

We will try and replicate the stop loading in the alpha but as I say the
main problem 99.9% of the time is the disconnect.

Cheers!

On 9 November 2016 at 10:48, Daniel Schürmann <email address hidden>
wrote:

> OK, so we can sort out the ISP and other Applications.
>
> It looks like Mixxx itself is not able to empty the network buffer in
> time. However the issue starts slowly and Mixxx is always able to pass some
> samples to the network (see attached graph).
> So it is not a deadlock. It is more a "slow down issue".
>
> What is your buffer size in hardware preferences? Does your under-run
> counter at the bottom of the hardware preferences count?
>
> ###
>
> The "stop loading" issue is tracked here
> https://bugs.launchpad.net/mixxx/+bug/1525738
>
> Since we have actually fixed one deadlock issue since 2.0:
> https://bugs.launchpad.net/mixxx/+bug/1565382 it is very important for us
> to know, if it ever happens with Mixxx 2.1 alpha, that a single deck just
> refused to load a track. Are you able to confirm this?
> If you manage to reproduce it with Mixxx 2.1 alpha a mixxx.log would be
> very helpful.
>
> This bug might be also related to
> https://bugs.launchpad.net/mixxx/+bug/1445298
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1623620
>
> Title:
> TWO SERIOUS BUGS in Mv2 (cache management maybe?)
>
> Status in Mixxx:
> Confirmed
>
> Bug description:
> Ok guys, we've been using Mv2 extensively now for several months and
> there are two serious issues that need fixing urgently.
>
> 1. Memory cache issue. If you play a long track- for example a 90
> minute radio play- (or several long tracks) and then attempt to load
> another, Mixxx simply stops broadcasting. Sometimes it doesn't TELL
> you it has, but mostly it just locks. It will also eventually just
> lock or throw off stream after several days of playing even if there
> have been no long tracks.
>
> 2. Any weakness in internet connection causes it to disconnect stream-
> even a nano second of fluctuation. For example, if I am broadcasting
> at 5pm and my neighbours get home and start to check their emails etc,
> there is a momentary drop in MY bandwidth as supplied by the ISP. This
> causes Mixxx to drop the stream. Every time.
>
> Note- we are 4 users all living in different areas, all on different
> ISPs, all on different computers. The only common ground is Windows
> 10.
>
> We LOVE Mv2 but the caching and robustness really needs sorting out
> urgently as we may be forced to replace it at our station (we would
> make a fab case study for you if you can make it work!).
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1623620/+subscriptions
>

[Daniel Schürmann (daschuer)]

I have dived though the libshout and compared it with Butt code, which is known as rock solid.

We use currently a broadcasting interval of 185 ms while Butt exposes this as preference option with 50 ms default. Your Mixxx engine interval is configured to 92.9 ms if this interferes with the broadcasting interval, we get a 92 ... 270 ms interval.

In case of network issues (EWOULDBLOCK) Butt waits up to 1 second via select() and flushes all buffers if it still fails to pass samples to the socket. Mixxx waits up to 10 seconds. A shoutcast server allows 30 s idle by default, before the source is disconnected.

Does it make a difference if you choose a smaller buffer in Hardware Preferences?
Please check if you have the same issues at 10 ms?

I will prepare a solution which keeps the interferences small but tries early to recover form EWOULDBLOCK

[Darren Smithson (darrenitu)]

Ah, great will try a lower buffer rate and see what happens :)

On 14 November 2016 at 00:21, Daniel Schürmann <email address hidden>
wrote:

> I have dived though the libshout and compared it with Butt code, which
> is known as rock solid.
>
> We use currently a broadcasting interval of 185 ms while Butt exposes
> this as preference option with 50 ms default. Your Mixxx engine interval
> is configured to 92.9 ms if this interferes with the broadcasting
> interval, we get a 92 ... 270 ms interval.
>
> In case of network issues (EWOULDBLOCK) Butt waits up to 1 second via
> select() and flushes all buffers if it still fails to pass samples to
> the socket. Mixxx waits up to 10 seconds. A shoutcast server allows 30 s
> idle by default, before the source is disconnected.
>
> Does it make a difference if you choose a smaller buffer in Hardware
> Preferences?
> Please check if you have the same issues at 10 ms?
>
> I will prepare a solution which keeps the interferences small but tries
> early to recover form EWOULDBLOCK
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1623620
>
> Title:
> TWO SERIOUS BUGS in Mv2 (cache management maybe?)
>
> Status in Mixxx:
> Confirmed
>
> Bug description:
> Ok guys, we've been using Mv2 extensively now for several months and
> there are two serious issues that need fixing urgently.
>
> 1. Memory cache issue. If you play a long track- for example a 90
> minute radio play- (or several long tracks) and then attempt to load
> another, Mixxx simply stops broadcasting. Sometimes it doesn't TELL
> you it has, but mostly it just locks. It will also eventually just
> lock or throw off stream after several days of playing even if there
> have been no long tracks.
>
> 2. Any weakness in internet connection causes it to disconnect stream-
> even a nano second of fluctuation. For example, if I am broadcasting
> at 5pm and my neighbours get home and start to check their emails etc,
> there is a momentary drop in MY bandwidth as supplied by the ISP. This
> causes Mixxx to drop the stream. Every time.
>
> Note- we are 4 users all living in different areas, all on different
> ISPs, all on different computers. The only common ground is Windows
> 10.
>
> We LOVE Mv2 but the caching and robustness really needs sorting out
> urgently as we may be forced to replace it at our station (we would
> make a fab case study for you if you can make it work!).
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1623620/+subscriptions
>

[Daniel Schürmann (daschuer)]

Thanks to Sebastien we have new test builds:
You can find a test build here for the next couple of weeks: https://mixxx.blaisot.org/
Please use them instead of the master alpha builds.

[Darren Smithson (darrenitu)]

Fantastic, thanks. Just downloading now- In the meantime we tested your
suggestion on the alpha and it won't work for us. After a few minutes we
remembered why we had the buffer set quite high- if we don't, long songs
(say around the 7 minute mark) start to stutter or click. We took it up to
46ms before that stopped. It played fine for a couple of hours but i
decided to try and force a disconnect to see if it would auto reconnect or
if that failed do a manual reconnect, sadly it failed on both the auto and
manual attempts, that is the auto failed and a manual had the tick to say
it was connected but it wasn't. Here is the log. :)

On 15 November 2016 at 07:56, Daniel Schürmann <email address hidden>
wrote:

> Thanks to Sebastien we have new test builds:
> You can find a test build here for the next couple of weeks:
> https://mixxx.blaisot.org/
> Please use them instead of the master alpha builds.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1623620
>
> Title:
> TWO SERIOUS BUGS in Mv2 (cache management maybe?)
>
> Status in Mixxx:
> Confirmed
>
> Bug description:
> Ok guys, we've been using Mv2 extensively now for several months and
> there are two serious issues that need fixing urgently.
>
> 1. Memory cache issue. If you play a long track- for example a 90
> minute radio play- (or several long tracks) and then attempt to load
> another, Mixxx simply stops broadcasting. Sometimes it doesn't TELL
> you it has, but mostly it just locks. It will also eventually just
> lock or throw off stream after several days of playing even if there
> have been no long tracks.
>
> 2. Any weakness in internet connection causes it to disconnect stream-
> even a nano second of fluctuation. For example, if I am broadcasting
> at 5pm and my neighbours get home and start to check their emails etc,
> there is a momentary drop in MY bandwidth as supplied by the ISP. This
> causes Mixxx to drop the stream. Every time.
>
> Note- we are 4 users all living in different areas, all on different
> ISPs, all on different computers. The only common ground is Windows
> 10.
>
> We LOVE Mv2 but the caching and robustness really needs sorting out
> urgently as we may be forced to replace it at our station (we would
> make a fab case study for you if you can make it work!).
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1623620/+subscriptions
>

[Daniel Schürmann (daschuer)]

Darren, do you have a log from the new builds for us?

[Darren Smithson (darrenitu)]

We are testing it tomorrow (Monday)- we had too many live shows on last
week to fit it in. But have scheduled it for tomorrow from 11am.

On 18 November 2016 at 19:19, Daniel Schürmann <email address hidden>
wrote:

> Darren, do you have a log from the new builds for us?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1623620
>
> Title:
> TWO SERIOUS BUGS in Mv2 (cache management maybe?)
>
> Status in Mixxx:
> Confirmed
>
> Bug description:
> Ok guys, we've been using Mv2 extensively now for several months and
> there are two serious issues that need fixing urgently.
>
> 1. Memory cache issue. If you play a long track- for example a 90
> minute radio play- (or several long tracks) and then attempt to load
> another, Mixxx simply stops broadcasting. Sometimes it doesn't TELL
> you it has, but mostly it just locks. It will also eventually just
> lock or throw off stream after several days of playing even if there
> have been no long tracks.
>
> 2. Any weakness in internet connection causes it to disconnect stream-
> even a nano second of fluctuation. For example, if I am broadcasting
> at 5pm and my neighbours get home and start to check their emails etc,
> there is a momentary drop in MY bandwidth as supplied by the ISP. This
> causes Mixxx to drop the stream. Every time.
>
> Note- we are 4 users all living in different areas, all on different
> ISPs, all on different computers. The only common ground is Windows
> 10.
>
> We LOVE Mv2 but the caching and robustness really needs sorting out
> urgently as we may be forced to replace it at our station (we would
> make a fab case study for you if you can make it work!).
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1623620/+subscriptions
>

[Sébastien BLAISOT (sblaisot)]

Warning, Darren, this build is only for debugging purposes.
It was NOT built with the release build server but on my own desktop, there could be differences in libraries versions or compilation, or packaging issues leading to uncontrolled behaviour.
Please be adviced that there could be remaining (code) bugs (this is a 2.1.0-pre-alpha), but also (build-env related) bugs.
Use it live at your own risks and as always, backup your preference folder first and be prepared to quickly switch back to 2.0.0-release if things go wrong.
the best is probably to test it in a staging environment, not in production.

[Darren Smithson (darrenitu)]

Yep, that's why I am testing it tomorrow on our back up server, :)

On 20 November 2016 at 19:17, Sébastien BLAISOT <email address hidden>
wrote:

> Warning, Darren, this build is only for debugging purposes.
> It was NOT built with the release build server but on my own desktop,
> there could be differences in libraries versions or compilation, or
> packaging issues leading to uncontrolled behaviour.
> Please be adviced that there could be remaining (code) bugs (this is a
> 2.1.0-pre-alpha), but also (build-env related) bugs.
> Use it live at your own risks and as always, backup your preference folder
> first and be prepared to quickly switch back to 2.0.0-release if things go
> wrong.
> the best is probably to test it in a staging environment, not in
> production.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1623620
>
> Title:
> TWO SERIOUS BUGS in Mv2 (cache management maybe?)
>
> Status in Mixxx:
> Confirmed
>
> Bug description:
> Ok guys, we've been using Mv2 extensively now for several months and
> there are two serious issues that need fixing urgently.
>
> 1. Memory cache issue. If you play a long track- for example a 90
> minute radio play- (or several long tracks) and then attempt to load
> another, Mixxx simply stops broadcasting. Sometimes it doesn't TELL
> you it has, but mostly it just locks. It will also eventually just
> lock or throw off stream after several days of playing even if there
> have been no long tracks.
>
> 2. Any weakness in internet connection causes it to disconnect stream-
> even a nano second of fluctuation. For example, if I am broadcasting
> at 5pm and my neighbours get home and start to check their emails etc,
> there is a momentary drop in MY bandwidth as supplied by the ISP. This
> causes Mixxx to drop the stream. Every time.
>
> Note- we are 4 users all living in different areas, all on different
> ISPs, all on different computers. The only common ground is Windows
> 10.
>
> We LOVE Mv2 but the caching and robustness really needs sorting out
> urgently as we may be forced to replace it at our station (we would
> make a fab case study for you if you can make it work!).
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1623620/+subscriptions
>

[Darren Smithson (darrenitu)]

Hi there, I think it might have cracked it! We did a 5 or 6 hour test and
did all the stuff we could think of (ie ran other programmes on the same
connection including an xbox 4.5GB game download) and it held the stream!

On 14 September 2016 at 20:23, Daniel Schürmann <email address hidden>
wrote:

> What is Mv2?
>
> Which version of Mixxx are you using? 64 or 32 bit?
>
> What means "just lock"? What does Mixxx and what not. Are the decks
> working, does the GUI respond?
>
> "This causes Mixxx to drop the stream" What does Mixxx do when it drops
> the stream?
> What does the server do?
>
> I have prepared a Alpha version, that writes a lot more diagnostic infos
> into the mixxx.log file.
> http://downloads.mixxx.org/builds/master/release/
>
> Some of the known broadcasting issues are already solved, but be warned,
> it contains a lot of other untested changes.
>
> Please try out if your issues are solved. If not, provide a mixxx.log of a
> faulty run.
> You will find it at %APPDATA%\Mixxx\mixxx.log
>
> ** Changed in: mixxx
> Status: New => Confirmed
>
> ** Changed in: mixxx
> Importance: Undecided => High
>
> ** Changed in: mixxx
> Milestone: None => 2.1.0
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1623620
>
> Title:
> TWO SERIOUS BUGS in Mv2 (cache management maybe?)
>
> Status in Mixxx:
> Confirmed
>
> Bug description:
> Ok guys, we've been using Mv2 extensively now for several months and
> there are two serious issues that need fixing urgently.
>
> 1. Memory cache issue. If you play a long track- for example a 90
> minute radio play- (or several long tracks) and then attempt to load
> another, Mixxx simply stops broadcasting. Sometimes it doesn't TELL
> you it has, but mostly it just locks. It will also eventually just
> lock or throw off stream after several days of playing even if there
> have been no long tracks.
>
> 2. Any weakness in internet connection causes it to disconnect stream-
> even a nano second of fluctuation. For example, if I am broadcasting
> at 5pm and my neighbours get home and start to check their emails etc,
> there is a momentary drop in MY bandwidth as supplied by the ISP. This
> causes Mixxx to drop the stream. Every time.
>
> Note- we are 4 users all living in different areas, all on different
> ISPs, all on different computers. The only common ground is Windows
> 10.
>
> We LOVE Mv2 but the caching and robustness really needs sorting out
> urgently as we may be forced to replace it at our station (we would
> make a fab case study for you if you can make it work!).
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1623620/+subscriptions
>

[Daniel Schürmann (daschuer)]

Great news!

Do you have a mixxx.log from this run?

We have done nothing for "holding" the stream. We have just improved the reconnect behavior in case of network issues. Maybe we can improve this behavior a bit more.

[Darren Smithson (darrenitu)]

I do but it's on the other laptop at the studio--- I will be back tomorrow
midday and send it then :)

On 28 November 2016 at 11:39, Daniel Schürmann <email address hidden>
wrote:

> Great news!
>
> Do you have a mixxx.log from this run?
>
> We have done nothing for "holding" the stream. We have just improved the
> reconnect behavior in case of network issues. Maybe we can improve this
> behavior a bit more.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1623620
>
> Title:
> TWO SERIOUS BUGS in Mv2 (cache management maybe?)
>
> Status in Mixxx:
> Confirmed
>
> Bug description:
> Ok guys, we've been using Mv2 extensively now for several months and
> there are two serious issues that need fixing urgently.
>
> 1. Memory cache issue. If you play a long track- for example a 90
> minute radio play- (or several long tracks) and then attempt to load
> another, Mixxx simply stops broadcasting. Sometimes it doesn't TELL
> you it has, but mostly it just locks. It will also eventually just
> lock or throw off stream after several days of playing even if there
> have been no long tracks.
>
> 2. Any weakness in internet connection causes it to disconnect stream-
> even a nano second of fluctuation. For example, if I am broadcasting
> at 5pm and my neighbours get home and start to check their emails etc,
> there is a momentary drop in MY bandwidth as supplied by the ISP. This
> causes Mixxx to drop the stream. Every time.
>
> Note- we are 4 users all living in different areas, all on different
> ISPs, all on different computers. The only common ground is Windows
> 10.
>
> We LOVE Mv2 but the caching and robustness really needs sorting out
> urgently as we may be forced to replace it at our station (we would
> make a fab case study for you if you can make it work!).
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1623620/+subscriptions
>

[Be (be.ing)]

Has this been fixed?

[Darren Smithson (darrenitu)]

Hi there! It's certainly far more stable than it was, oddly enough we were
talking about this only a couple of days ago and saying we should promote
Mixxx on our website! It still disconnects at odd times, but I think this
may be more to do with w10c issues (taking over resources etc) than Mixxx
itself now. I'll get the guys to collate their logs and I'll send them over
to you for you to review- I'll wait til there's another disconnect :)
Thanks again for all your help!
Darren

On 11 November 2017 at 15:09, Be <email address hidden> wrote:

> Has this been fixed?
>
> ** Summary changed:
>
> - TWO SERIOUS BUGS in Mv2 (cache management maybe?)
> + broadcasting disconnects
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1623620
>
> Title:
> broadcasting disconnects
>
> Status in Mixxx:
> Confirmed
>
> Bug description:
> Ok guys, we've been using Mv2 extensively now for several months and
> there are two serious issues that need fixing urgently.
>
> 1. Memory cache issue. If you play a long track- for example a 90
> minute radio play- (or several long tracks) and then attempt to load
> another, Mixxx simply stops broadcasting. Sometimes it doesn't TELL
> you it has, but mostly it just locks. It will also eventually just
> lock or throw off stream after several days of playing even if there
> have been no long tracks.
>
> 2. Any weakness in internet connection causes it to disconnect stream-
> even a nano second of fluctuation. For example, if I am broadcasting
> at 5pm and my neighbours get home and start to check their emails etc,
> there is a momentary drop in MY bandwidth as supplied by the ISP. This
> causes Mixxx to drop the stream. Every time.
>
> Note- we are 4 users all living in different areas, all on different
> ISPs, all on different computers. The only common ground is Windows
> 10.
>
> We LOVE Mv2 but the caching and robustness really needs sorting out
> urgently as we may be forced to replace it at our station (we would
> make a fab case study for you if you can make it work!).
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1623620/+subscriptions
>

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/8644