Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: [crashware] foo_chronflow (Read 185372 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

[crashware] foo_chronflow

Here you will find the latest version of this plugin:
http://chron.visiondesigns.de/foobar2000/f...flow_v0.3.0.zip

I am starting this topic because the messy topic was closed but we still do not have a new topic.

I recognized something strange: I am using the chronflow panel in a cui with panel splitter layout. I don't know it the splitter is causing this or chronflow itself.
Sometimes when I maximize the minimized Foobar all covers have been gone.
When I exit foobar I get a pure virtual function call. 

Has someone else experienced something similar?

[crashware] foo_chronflow

Reply #1
Uhm how helpful is it if you open this thread? One of the main points of the mods to close Chronial's thread was that he was supposed to set up a proper first post that he could update whenever necessary.

So this thread will probably end the same way as the last one

[crashware] foo_chronflow

Reply #2
I see your point(I knew that before). But where should I post my bug report then? To have severeal topics about one plugin is also unecessary. I wrote a pm to chronial. If there is a new topic by chronial this topic can be closed and deleted.
@ mods if you want you can rename this topic.
All I want is to know if this is a bug from foo_chronflow and if someone can recognize something similar...

[crashware] foo_chronflow

Reply #3
Quote
I recognized something strange: I am using the chronflow panel in a cui with panel splitter layout. I don't know it the splitter is causing this or chronflow itself.
Sometimes when I maximize the minimized Foobar all covers have been gone.
When I exit foobar I get a pure virtual function call

That's pretty much not helping me here. What does "all covers have been gone" mean? Is the panel black, are the covers white, do you still see the album title... What does the panel look like?
Also what's a "panel splitter layout"?

[crashware] foo_chronflow

Reply #4
That's pretty much not helping me here. What does "all covers have been gone" mean? Is the panel black, are the covers white, do you still see the album title... What does the panel look like?

Sorry nativ german here  The panel is totally black.No covers nor the the name is available.
Also what's a "panel splitter layout"?

A layout created with this plugin here:
http://www.hydrogenaudio.org/forums/index....showtopic=62114

I don't knowif it depends on this. The bug is repeated from time to time. I try to find the circumstances when it appears but still itis quite mysterious.

[crashware] foo_chronflow

Reply #5
90% caused by foo_uie_panel_splitter. The Introduction says it all: "It is a bit like panel ui".
This component is very demanding for the hosting plugin to be written absolute correctly. This is uncomparable to quite anything out there, since I'm using OpenGL in my panel.

Short: Don't use stuff like panels_ui. There is a very good reason the foobar developers did not like it. The concept itself is bad. So quite likely anyone who will implement such a concept will also not do it right.

[crashware] foo_chronflow

Reply #6
Don't use stuff like panels_ui. There is a very good reason the foobar developers did not like it. The concept itself is bad. So quite likely anyone who will implement such a concept will also not do it right.
What concept would that be? An advanced UI with arbitrary user chosen placement of content panels?
It's easy to pinpoint various flaws in PUI's implementation, but the idea looks good enough to me.

[crashware] foo_chronflow

Reply #7
This has been discussed enough in the past, but well: here we go again:
1. The foobar titleformatting language is meant to format strings from thousands of datasets as fast as possible. This string formatting language/compiler/parser is misused as a programming language.
2. Hoping that people not interested in programming could be able to do it. The concept is not "arbitrary user chosen placement of content panels", but a programming language is given to the user that allows him to write extremely complicated scripts without having serious understanding of programming.

The result: at least 90% of the users are messing with something they don't understand.
You might say "but it works and looks nice" - while this might be correct, this is something a serious coder can not accept. Things don't just have to seem to work, but it has to be done right.

[crashware] foo_chronflow

Reply #8
Hi, need some help here =)

What I have now:



My config:



Could somebody please tell me what I need to change in conf, so that coverart in chronflow and in playlist where in the same order?

Sorting in Playlist is done by %path_sort%

[crashware] foo_chronflow

Reply #9
Chronial, do you have any plans to make coverflow as an element for default ui...? It could be a dream...

[crashware] foo_chronflow

Reply #10
That is not possible.


[crashware] foo_chronflow

Reply #12
Not sure if this is the thread to ask, but does anyone know if there's a way to get foo_chronflow to source the id3 album art tags, like foo_uie_albumart does, instead of looking for an image file in the directory?  The component is seamless otherwise.  Thanks in advance!

[crashware] foo_chronflow

Reply #13
Hi Chronial

Could you add an option to always use a specific playlist? I love your component but don't like how it messes up my playlists

[crashware] foo_chronflow

Reply #14
Hi, maybe a bug report here on latest Chronflow version.

Sometimes (rarely but from time to time) the displayed "Album title" information doesn't match the preview ! 

Here's a self-explanatory image. Look how the two generated strings are different :



FYI the correct string is the upper one, so the green string is incorrect.

But that's not all ! I'm using exactly the same titleformat string for "Album source > Sources" and "Display > Album title" (for testing purposes). That means the green (incorrect) string is also the path where Coverflow is trying to find the current cover. So Coverflow just can't find the cover (as you can see in the pic), even if the path (preview string) appears to be correct.

Reloading sources won't work. Sometimes a foobar restart will solve the problem... and sometimes not.

At first look the problem seems to come from Coverflow, and it seems to affect both the "Album title" displayed string and the "Sources" handling for cover finding. Chronial, what do you think ?
(I can provide the used titleformat string, but I don't think it will change anything)

---------------------------------------------------------------------------------------------

EDIT - maybe a hint for Chronial : I'm not sure, but the problem seems to come when the same artwork exists at two different paths (at least it was the case for all three problematic artwork I've checked). Maybe it causes Chronflow to mess around with paths ?
Deleting one of the two artwork solves the problem sometimes (and sometimes not). But it's not a valid solution for me, since I sometimes need to have the same artwork at several paths (e.g. an album at a path beginning with "LOSSLESS" and some rare bonus tracks of the same album at a path beginning with "LOSSY").

---------------------------------------------------------------------------------------------

EDIT2 : and a small feature request : could Chronflow generate a text report of all missing artwork ?
Preferably with all the Source Paths where Chronflow expected to find artwork but didn't.
e.g. :
Artist 1 - Album 1 : Source Path 1
Artist 2 - Album 2 : Source Path 2
Artist 3 - Album 3 : Source Path 3
Etc.
Thanks in advance.

[crashware] foo_chronflow

Reply #15
From my experience I'd say the error is on your side. That kind of bug can't just be caused only on one PC.

The preview is generated from a random Track - it is not supposed to macht the "green string".

And as said above I'm pretty sure the second problem is also caused by a mistake on your side. You should realise that the Album Title string is generated again instantly, but the Cover Source only gets refreshed when you press "Reload Sources".

Quote
EDIT - maybe a hint for Chronial : I'm not sure, but the problem seems to come when the same artwork exists at two different paths (at least it was the case for all three problematic artwork I've checked). Maybe it causes Chronflow to mess around with paths ?
Deleting one of the two artwork solves the problem sometimes (and sometimes not). But it's not a valid solution for me, since I sometimes need to have the same artwork at several paths (e.g. an album at a path beginning with "LOSSLESS" and some rare bonus tracks of the same album at a path beginning with "LOSSY").

Only one (random) Track per Album is used to generate the cover image path. I guess your problem is that you combine tracks to albums that result in different cover paths.

[crashware] foo_chronflow

Reply #16
Thanks Chronial. I think I understand what's happening now. And in that case, I'd say that my problem (if we don't want to call it a bug) may simply come from the way Chronflow handles covers (so there would be no error on my side either).

Why ? Because you've just said it : only one (random) track per album is used. So why a random track ? Couldn't it be simply the "now playing" track for instance ? (when there is one of course). And random ONLY if there is no "now playing" track.

I'm pretty sure that is what's happening in my case : I am playing track A on album A, but Chronflow tries to find cover for (random) track B on album A, while track B is stored elsewhere on my HD (because track A might be lossless and track B might be lossy for instance) and track B doesn't have a cover (or has a different cover) while track A has a cover.

So I don't know if we can call it a bug or not... but maybe there's some room for improvement in a future Chronflow version.

Thanks again for this beautiful component.

PS : what do you think of my feature request ? That text log would definitely help me a lot.

[crashware] foo_chronflow

Reply #17
Why ? Because you've just said it : only one (random) track per album is used. So why a random track ? Couldn't it be simply the "now playing" track for instance ? (when there is one of course). And random ONLY if there is no "now playing" track.


Wouldn't that lead to having to reload every cover every time you changed track?

[crashware] foo_chronflow

Reply #18
I guess only Chronial can tell : he's the only one to know how Chronflow works.

I'm just pointing out what we could maybe call a limitation of current (and already excellent of course) Chronflow version :

- for example if we have a compilation of greatest hits, but we decide that instead of displaying ONE cover for the whole album (compilation covers are often ugly) we want to display one different cover per album track (the CDS covers for instance).

- or if we have a "logical" album whose tracks are "physically" distributed in several places on a HD (e.g. an album mixing lossless tracks and lossy tracks, if we have decided to have a "lossless" directory for all lossless tracks and a separate "lossy" directory for all lossy tracks), and if we want covers to be different for the lossless part and the lossy part (for whatever reason - e.g. to emphasize the fact that a given track is lossy).

Maybe Chronial can find a way that doesn't need to reload every cover ?

Just my two cents.

[crashware] foo_chronflow

Reply #19
Hi Chronial,

could we expect an update of Chronflow that allow (option?) to bind the flow with a specific playlist or the active playlist ?

i always miss a simple 'Play' action for double-click on a cover.

Thanx for giving us news about planned releases if some (i hope so  )

[crashware] foo_chronflow

Reply #20
Hi Chronial,

could we expect an update of Chronflow that allow (option?) to bind the flow with a specific playlist or the active playlist ?

i always miss a simple 'Play' action for double-click on a cover.

Thanx for giving us news about planned releases if some (i hope so  )


I second this. This is the only feature that i feel is missing from chronflow.
Any news on updates would be great.

[crashware] foo_chronflow

Reply #21
Quote
only one (random) track per album is used. So why a random track ? Couldn't it be simply the "now playing" track for instance ? (when there is one of course). And random ONLY if there is no "now playing" track.

Quote
Wouldn't that lead to having to reload every cover every time you changed track?
Exactly. That's the technical side of the reason why it's not gonna happen

Quote
- for example if we have a compilation of greatest hits, but we decide that instead of displaying ONE cover for the whole album (compilation covers are often ugly) we want to display one different cover per album track (the CDS covers for instance).
So here is the conceptual side of the reason why it's not gonna happen: That just doesn't make any sense. One Album -> one cover. It's just that simple. A cover display plugin should not offer any means to fix ugly covers.

Quote
- or if we have a "logical" album whose tracks are "physically" distributed in several places on a HD
You will have to think about a cover storage method that fixes this (e.g. storing covers in c:\music\albumcovers\%album artist% - %album%.jpg).

Quote
if we want covers to be different for the lossless part and the lossy part
See above

Quote
i always miss a simple 'Play' action for double-click on a cover.
That just doesn't fit with foobar's concept: foobar is a playlist-bound player. There is no way (in concept, technically there is one) to play songs that are not part of a playlist. Live with it or switch to another player.
You can use "replace playlist" or "add to new playlist" to have the album playing instantly.

Quote
could we expect an update of Chronflow that allow (option?) to bind the flow with a specific playlist or the active playlist ?
Yes, you can, but not in the near future.

[crashware] foo_chronflow

Reply #22
Quote
i always miss a simple 'Play' action for double-click on a cover.
That just doesn't fit with foobar's concept: foobar is a playlist-bound player. There is no way (in concept, technically there is one) to play songs that are not part of a playlist. Live with it or switch to another player.
You can use "replace playlist" or "add to new playlist" to have the album playing instantly.

Quote
could we expect an update of Chronflow that allow (option?) to bind the flow with a specific playlist or the active playlist ?
Yes, you can, but not in the near future.


thanx for anwser, but no good news ... what a shame.

[crashware] foo_chronflow

Reply #23
Thanks chronial. I understand your choices and the subsequent limitations (even if I would have done things differently, but that's easy to say afterwards). No problem.

What about the following option ? "Single-click on the highlighted cover --> Shows the cover in full resolution inside a separate window" (whose max height and screen position would be user-definable via the prefs). That would make Chronflow the best artwork-browsing component ever ! (for me of course)

And please try to think about the "covers not found" text log (you haven't replied about it yet so I don't know if you plan on implementing it).

Thanks again for making Chronflow such an enjoyable experience. 

[crashware] foo_chronflow

Reply #24
Hello ! Is it possible to configure foo_chronflow to look like Graphical Browser (foo_uie_graphical_browser.dll)?