Comment 3 for bug 1623620

Revision history for this message
Darren Smithson (darrenitu) wrote : Re: [Bug 1623620] Re: TWO SERIOUS BUGS in Mv2 (cache management maybe?)

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 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
>