Forums / Feature Request / [ ] Showing 2 or 3 degrees of...

[ ] Showing 2 or 3 degrees of separation for a band

Bloopy·10 replies

[ ] Showing 2 or 3 degrees of separation for a band
7 years ago
Mar 16, 2016 - 9:02am
Currently as soon as a band reaches 30 bands within 2 degrees of separation, B2B stops showing the 3rd degree of separation in their family tree, regardless of how big or small their tree otherwise was. This is quite an unbalanced way of determining how many degrees to show, for example:
displays 412 bands in 3 degrees, since only 16 bands within 2 degrees
displays 222 bands in 3 degrees, since only 17 bands within 2 degrees
displays 197 bands in 3 degrees, since only 29 bands within 2 degrees
would have about 78 bands within 3 degrees, instead displays 30 bands within 2 degrees
would have about 73 bands within 3 degrees, instead displays 30 bands within 2 degrees
would have 69 bands within 3 degrees, instead displays 68 bands within 2 degrees
would have about 68 bands within 3 degrees, instead displays 32 bands within 2 degrees
would have 43 bands within 3 degrees, instead displays 38 bands within 2 degrees

Point being that the first three examples are better candidates for being reduced to showing 2 degrees of separation than the others. It'd be much better if the reduction was determined by how many bands are within 3 degrees, eg. a limit of 200. Or perhaps have both criteria so that the first two examples aren't reduced to trees of just 16 & 17 bands.
Tree Depth
2 weeks ago
May 24, 2023 - 2:06pm
The family tree depth does go to a 3rd degree if 2 degrees has less than 40 bands:

If there are any other examples where this limit isn't good enough, please let me know.

2 weeks ago
May 24, 2023 - 8:00pm
You missed my point so I'll just take the X out of the thread title again. I put this forward as one of my "least favorite problems" about the site which I was quite passionate about, and I'm taking about fundamentally changing the algorithm, not just tweaking the number.

What I'm saying is, for the edge cases to have family trees of more democratic sizes, the decision on whether to take the depth to a 3rd degree should depend on how many bands are within >three< degrees. It doesn't help that most of my examples above are way outdated. I'll try to tell it as a story:

- Suppose a typical band somewhere near a thicker part of the tree has 29 bands within 2 degrees, and 300-ish bands within 3 degrees. Tormentor for example:

- However, a band in the New Zealand scene I'm working on might have say 16 bands within 2 degrees and 50 bands within 3 degrees

- If I really focus on filling out that particular band's tree, what I'd find is that it soon goes over the limit, ie. now more than 30-40 bands within 2 degrees, and yet it still has only 70-90 bands within 3 degrees (either because the connections at that distance are more confined, involve the same members in different configurations, or we just haven't worked extensively everywhere). So why is Tormentor allowed a tree of 300, while my work gets 'punished' and the band's not allowed a tree of 90? Sometimes I'm in contact with a member of the band I'm focusing on so it's a shame not to be able to show them a tree with 3 degrees any more.

- In the extreme case, I've added artists with 40+ solo projects, but they only have one or two connections into the tree. These are the Redsk and Richard Ramirez examples from above. Showing the 3rd degree on these would only add around 2-5 more bands to their tree!!
2 weeks ago
May 24, 2023 - 8:57pm
You are correct, I didn't fully grasp what you were trying to relay although I think I understand it more now.

To try and simply things both in my thick head and for the site, do you have a lower and upper bound that you would like to see for the 3rd degree of bands to be displayed?

For example: show 3 degrees if
- 2 degrees < 40 bands cumulative
- 3 degrees < 100 bands cumulative

Am I getting a better understanding of your concern? The only reason that I'd want to keep a lower bound for 2 degrees before checking on 3 degrees (ie, 2 degrees < 40) is that the database query to pull the bands for 3 degrees is *very* slow and taxing.

If we can keep a reasonable 2 degrees minimum before executing the 3rd degree database query and then evaluating the total number and display the 3rd degree only under a certain threshold (total < 100 cumulative for example) would be manageable I believe.

2 weeks ago
May 26, 2023 - 7:16am
Maybe there are ways to make things less taxing. How about if the 2 degrees bound wasn't a number, but rather a flag that gets put on each band at some point as their tree grows? For example:

1.) Retrieve all the bands that are 2 degrees away (if you've already reached 100 or the band is flagged in step 3. you stop here)

2.) Retrieve the 3rd degree. Would it be more efficient to loop through the 2nd degree bands 1 at a time or maybe 5-10 at a time? Meaning, retrieve the bands 1 more degree away in smaller portions so you can keep checking whether you've exceeded 100 along the way (or maybe 105 to allow for threshold mentioned below).

3.) After doing the above, you could store a flag against bands that hit 105+ bands within 3 degrees (small threshold in case bogus entries/connections get deleted via Shambles). Then you know you don't need to explore 3 degrees for them again. Only in very rare cases a correction via Shambles might remove a major connection and maybe then someone could clear the flag manually.

Bonus overthinking.) I realise using a loop in step 2.) may be taxing too, but perhaps it opens up ways to make it less taxing again. Eg. skipping one-man bands. Skipping 2nd degree bands where every member is either also in a 1st degree band or only in the one band (depends if you have the artist IDs from the 2 degrees query to play with I guess).

The B2B geek in me is still keen to see all the weirdly-shaped trees. The edge cases where an artist's bandmate has 67 solo/non-connective projects and 2-3 bands actually serving as their connection into the tree. But not if it means slowing things down with 70 queries. This bandmate of Richard Ramirez is a good example where the 3rd degree could do wonders and show where the 2-3 links actually go:
On Demand
2 weeks ago
May 26, 2023 - 10:07am
I tried something similar to your suggestion on the old site where I'd try and track the family tree growth, cache it at various times, etc. However this ultimately would blow up in my face. The problem lies in database calls where it will kill you with either:

1) Very complex / intensive queries
2) Way too many queries

Here, querying the DB for every band as a tree grows would blow up. Even when I recorded that data as I went, it will still blow up whenever any single tree was updated which triggers a recursive rebuild of all other bands' trees. There were times on the old site where the entire server would run slowly for 12 hours as band after band had to have their trees re-calculated.

I can't go back to that system and put the server at risk again. However as a possible stop gap, we can try this:

1) Set reasonable defaults to catch most cases:
- load 3rd degree if 2nd degree < 40(?) bands cumulative
- display 3rd degree if < 100(?) band cumulative
(since you are more in the weeds with the edge-cases, you can pick the default numbers)

2) In the case the 3rd degree doesn't display, I can add a button for logged in users to force load and display the 3rd degree on demand. That way for the edge-cases that do not load, you can still fire it up manually which won't tax the server terribly if it's only on demand as one-offs. This would even apply to all bands, even those with already big 2nd degree trees. If you wanted to be punished with the full 3rd degree display for any band, you would then always have that option.

1 week ago
May 26, 2023 - 7:35pm
I don't mean ongoing tracking/caching of the trees. I just mean when a site visitor views a band's page and the 3rd degree is queried. If that query tops 100, would you then set a flag on that band so the query is never even tried again for them? Because there are plenty of cases where a 3rd degree far exceeding 100 is shown now (eg. Tormentor). There's not much point hiding those 3rd degrees if the query is still running in the background every time, haha. So my idea with the flag is to reduce all those queries going on, which could maybe allow room to increase the 40 to a larger number and have more 3rd degree queries running for bands where we would actually display the 3rd degree, due to their tree being something like this:

band -> 18 bands -> 29 bands -> 45 bands

(ie. 18 + 29 = 47 within 2 degrees but still < 100 overall)

Anyway, what you said sounds good, with 40 & 100 as a place to start. Though maybe one exception could be be if you have something like this:

band - 1 band - 5 bands - 150 bands

Because then it'd be kind of a downer to show a tree of only 6 bands to the public. Maybe always show the 3rd degree if < 8 bands within 2 degrees?
1 week ago
May 31, 2023 - 9:38am
I've uploaded the range limits for family trees as discussed, including a 2 degree minimum to always load the 3rd degree as mentioned:

"band - 1 band - 5 bands - 150 bands"

I've also brought back in the old site's listing of degrees displayed as well as total number of bands (so I can double check that the numbers are correct).

I can skip the "Load 3rd Degree" button if it's not necessary. Let me know if what's up now fulfills what you were hoping to see from Family Trees.

6 days ago
Jun 2, 2023 - 11:23pm
A 'load 3rd degree' button for logged in users would be fantastic I think.

Bands that are close to the 40 and 100 limits look good:

The one issue I notice is the text for the bands that were showing 3 degrees and now show 2 degrees is mistakenly saying "3 degrees of separation for..."

Does that mean the 3rd degree calculation is still happening in the background as I wondered?
2 days ago
Jun 7, 2023 - 11:47am
Do you have an example of a band showing only 2 degrees but saying "3 degrees" instead? Seeing one would help a bunch in debugging it.

I'll try and get that "Load" button going here before long.

1 day ago
Jun 8, 2023 - 3:57am
Mapping the Rock 'N Roll genome since 2005