Hi Marcos,
if it is no deal than one of the later would be nice.
Thank you,
Daniel
Am 15.11.2014 um 03:27 schrieb Marcos Cardinot:
Hi all,
Currently the library shows the cover hash (integer) in the tooltip of
the cover column.
IMHO this info is not so useful, maybe we could disable tooltip
Hi all,
Currently the library shows the cover hash (integer) in the tooltip of the
cover column.
IMHO this info is not so useful, maybe we could disable tooltips for this
column OR use another info, such as cover location or source type... what
do you think?
all the best,
Marcos
2014-11-14 9:03
Hello,
I'll try it and try to solve problems.. Just thinking should this be
parsed in parseHeader but try this one out to find if it's working
correctly first.
Thanks,
Tuukka
2014-11-14 10:44 GMT+02:00 Max Linke :
> Oh thanks that is good
>
> There already is a PR for this.
>
> https://github.com
Oh thanks that is good
There already is a PR for this.
https://github.com/mixxxdj/mixxx/pull/368
There still are some issue with this. The tests are failing and mixxx crashes
after you scroll a bit with a warning that too many files are open. I would
appreciate it if you could help there or mayb
Hello,
I noted that FFMPEG doesn't build anymore because of missing Albumart
stuff. I'll fix that and submit pull request later on.
Tuukka
2014-11-07 20:15 GMT+02:00 Ilkka Tuohela :
>
>
>> On 07 Nov 2014, at 16:40, Max Linke wrote:
>>
>> On Fri, 7 Nov 2014 01:01:51 +0200
>> Ilkka Tuohela wrote:
> On 07 Nov 2014, at 16:40, Max Linke wrote:
>
> On Fri, 7 Nov 2014 01:01:51 +0200
> Ilkka Tuohela wrote:
>
>> Hi,
>>
>> The newly merged album art code in master is missing implementation for Opus
>> codec, causing linker errors if libopus is detected and enabled.
>>
>> I added following t
On Fri, 7 Nov 2014 01:01:51 +0200
Ilkka Tuohela wrote:
> Hi,
>
> The newly merged album art code in master is missing implementation for Opus
> codec, causing linker errors if libopus is detected and enabled.
>
> I added following to my hack branch to make it compile without explicitly
> disablin
Hi,
The newly merged album art code in master is missing implementation for Opus
codec, causing linker errors if libopus is detected and enabled.
I added following to my hack branch to make it compile without explicitly
disabling opus codec, but I’m not at all sure about the code.
http://tuohe
So far so good! Too bad so few of my tracks have cover art. I'll work
on adding cover art support to LateNight soon.
Unrelated to the overall quality of the patch -- is there any way we can
fix the bug where if the available library columns change, my entire
column layout gets fucked up? It's r
I merged the cover art branch into master an hour ago. You can grab the code and
try it out. If you start from an old config you will have to rescan your library
to see the covers and likely also activate the column in the libraryview. Deere
is currently the only skin that uses cover-art widgets ou
Hello,
Sounds very reasonable bit like they do it Chrome and Firefox (and
others) that there is isolation for untrusted part (like Flash that
tends to crash) and stuff that is rock solid. How much work this will
need it obviously goes to 1.13?
Tuukka
2014-10-20 17:10 GMT+03:00 RJ Ryan :
> No, I d
No, I don't think it's worth blocking the feature. I do think long-term we
want to be touching all untrusted data in separate processes though --
talking to the cachingreaders via FIFO, etc. It's a big hassle but it would
eliminate a category of crashes we see.
On Mon, Oct 20, 2014 at 9:05 AM, Owe
On Mon, 2014-10-20 at 09:01 +0300, Tuukka Pasanen wrote:
> Hello,
> Can't tell why no parsing in separate process but sound bit harsh to
> me and doesn't really fix the problem of crashing..
That's my point, RJ's contention is that if we don't have a separate
process, we will get crashes. So I a
Hello,
Can't tell why no parsing in separate process but sound bit harsh to
me and doesn't really fix the problem of crashing..
I have question about compiling on mac OS X 10.6 (normal Mixxx
compiles just fine) when compiling thins Pull request branch with
'scons ffmpeg=0 shoutcast=0 machine=x86_6
Please answer my second question about why we aren't parsing audio
metadata in a separate process.
On Sun, 2014-10-19 at 00:35 +, re-cy...@hushmail.com wrote:
> "I think crashing on totally crap data is not completely
> unreasonable as long as we can figure out some way of making it
> debuggab
Crashing is not a reasonable response to a parse error, PERIOD.
On Oct 18, 2014 4:13 PM, "Owen Williams" wrote:
> Is taglib really that crash-prone? Is this really a common issue? I
> think crashing on totally crap data is not completely unreasonable as
> long as we can figure out some way of m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
"I think crashing on totally crap data is not completely
unreasonable as long as we can figure out some way of making it
debuggable."
*raises hand*
As someone who has used Mixxx for live gigs, where it crashed
enough times during various sets to sabo
Is taglib really that crash-prone? Is this really a common issue? I
think crashing on totally crap data is not completely unreasonable as
long as we can figure out some way of making it debuggable.
I don't see how processing files for cover art is any different than
processing files for audio da
The main limitation with QtConcurrent is that it uses a single global
thread pool -- and currently we use 4 worker threads in our global
thread pool (for parsing 3rd-party libraries, etc). There is no notion
of auto-scaling or the ability for sensing whether we are overloading
the system inherent i
Am 18.10.2014 um 00:31 schrieb Max Linke:
> I haven't noticed any taglib crashes with mixxx. Plus the covers are all
> extracted in seperate threads.
I have not experienced any crashes during the tests as well, so the
issue is hopefully none.
I was just trying to collect the point that might be ris
> I think we should carefully consider risks and chances for the cover art
> support merge.
Marcos and I have taken great care that we get rid off all issues before merging
this PR. So far I have test reports from Daniel and Jus, which gave us valuable
input and bug reports which have been fixed b
Hi Developers,
I think we should carefully consider risks and chances for the cover art
support merge.
My impression is that the branch has a good overall quality and is a real
benefit for a upcoming 1.12 version.
What are the points of risks, that makes this different to other pull
requests.
He
That model has not worked well in the past. It doesn't matter how many
warnings there are, people will see "album art!", turn it on, and then
get angry if/when it crashes.
The new model I'd like to propose is:
* Enable an unstable-but-desirable feature (like cover art) by default
in development a
Hello,
Ok I'm totally with this but I also understand RJ concerns about
hitting unwanted behavior.
Could this be integrated and only turned on if user makes it with BIG
FAT WARNING about
it is little bit experimental and polish it to 1.13?
Tuukka
2014-10-12 15:13 GMT+03:00 Max Linke :
> That is e
That is exactly how it works. Currently ew only support local covers. We have
some code to also download covers from amazon but I'm not sure if that will make
it.
Here is the algorithm that decides which cover we are loading.
// Search Strategy
// 0. If we have just one file, we will get
Hello,
Does this support scenario when you have used something like Beets
(http://beets.radbox.org/) and allready have cover.jpg (or something)
in every directory that contains music? It's nice to have somekind of
downloader but there should be also support people like me who like to
organize their
I'll take a look. I'm worried about:
1) Increasing the risk of untrusted / junk data taking down Mixxx
2) Increasing the risk we tickle graphics driver bugs.
But ultimately we're going to add cover art at some point so why not now.
This release will be so massive that people probably aren't going
Hi,
Marcos Cardinot, one of our GSoC students, has implemented basic support for
album covers in mixxx. I want to merge this as the last big feature for 1.12
next week.
The code can be found at.
https://github.com/mixxxdj/mixxx/pull/278
To test this you have to build the code yourself right now
28 matches
Mail list logo
