Thanks for the feedback and hard work, we will wait for it 
Currently I am on:
pi@pihole:~ $ pihole -v
Pi-hole version is development v5.0-134-g60f0ab51 (Latest: v5.1.1)
AdminLTE version is new/mac_clients v5.0-403-ga901489a (Latest: v5.1)
FTL version is new/mac_clients vDev-661dad9 (Latest: v5.1)
Am I understanding that now the best way to keep up with this version to switch over to the dev branch? Is that by doing:
pihole checkout dev
or do I need to do each component:
pihole checkout core dev
pihole checkout web dev
pihole checkout ftl dev
Or should I stick on this branch for now? I know there was DB changes with this, so don't want to corrupt things by switching out of this branch prematurely.
It has not been merged now. I'm sure, DL6ER will post a message here when he merged the branches into development.
For now you should stay on this branch if you don't want to loose the ability to define clients by MAC, hostname, etc. and want to avoid to delete your long-term-database.
This two will be sufficient.
Current status is: Waiting for FTL#845 to get merged.
Then I will update all the features branches floating around. And I will also mark them as ready-to-be-merged into development.
Depending on the team's review abilities this may happen within minutes to hours to days. I hope that we can release FTL v5.1.1 tomorrow which also means you will get all the updated branches tomorrow.
I could already do it now, however, there are two drawbacks:
- I have double amount of work (I don't care too much about this, but see no. 2)
- There would be a needless extra merge commit. It is just cleaner to wait for
release/v5.1.1to be done in order to reduce the number of merge commits floating around. They are just noise. However,. given the complexity of the currently discussed branches, arebasewould result in even (much) more work than an ordinarymergewhich is why I'll prefer the latter.
I hope this makes my motivation clearer. It's not about me simply not wanting to do it.
Sorry if my post came across in any way other than just seeking clarification. I totally understand that in the world of software development, things take time. I also get that cleaner is better, and would wish extra work on no one.
I do want to take a moment to thank you (and the rest of the team) on putting this all together. Specifically this feature is a really great one, that is helping to fine tune my setup for the different use cases in my household.
2 Likes
I don't think your post comes across as demanding in any way. Re-reading his reply, I don't think he received it this way, either, so all good.
There seems to be a lot of work going on behind the scenes. They added another optimization yesterday and still have one more bugfix prepared and even an update for the dnsmasq core to the (today released!!) dnsmasq v2.82.
How cool it this!
Also, @DanSchaper commented that the update of dnsmasq will push FTL to v5.2 so v5.1.1 will maybe be skipped. We can stay tuned for more awesome Pi-hole things to come.
This feature branch (new/mac_clients) has been updated to the latest version of FTL (release/v5.2).
@DL6ER Thank you very much! Will the AdminLTE also be updated so changes (for example Conditional Forwarding on DNS page) can be updated?
Thanks for your hard work 
Yes, however, the AdminLTE branch is still awaiting two more PRs to be reviewed + merged, first.
Alright, thank you very much for your fast reply
PRs have been merged, so I just updated the web branch as well now. Please test if adding custom IPs still works, I had to resolve some merge conflicts and I did so with a "best efforts" approach. I'm limited to my mobile development system right now so I cannot really do much to test my changes. If adding custom IPs in the dropdown select menu still works (Groups -> Clients page), then everything went well.
Just tried it, seems to work! Thank you very much
Thank you very much for pushing the new release to this. pihole is working exceedingly well now. From my experience testing release/5.2, it seems to fix alot of stuff.
One further addition is to ask the kernel immediately (through Netlink) if it knows the MAC address of a new client before doing the group lookups in the database. This should make recognizing clients by their MAC addresses finally pretty reliable.
Please test this some more, but I have the feeling that this feature has become ready for inclusion in the v5.3 release.
This is a great addition!! Will it be possible for this MAC association with the client name to be used (or an option to be used) in the client tables and client activity graph vs. the IP address in the future. This makes it easier to identify the IPv6 addresses that need to be added manually, but it would be really slick if this fed the tables and graphs too.
What do you mean? When using the MAC to identify clients, you do not need to add IPv6 clients manually. They will get identified by the MAC address.
You mean grouping the different IP addresses into (let's say) "virtual" clients? There was a discussion about this some time ago and everyone seems to have agreed that this may not be what you want, it may be too much hand holding. The MAC address is the same interface. Apparently, there are often multiple clients (each with its own address) on an interface, e.g., docker containers. They can now distinguished by their IP addresses. When grouping them together, this would not be the case any more.
Maybe an optional feature? In this case -> Open a Feature Request and hope that many find it useful = vote for it. Either this or write the code yourself (and please submit it!) to get it 
Nothing that complicated. I am referring to the host name being listed based on the MAC address in the dashboard client graphs and tables rather than the constantly updating IPv6 address that pulls the host name from the ISP, or should that already be happening with this change (in my case it is not). The network table under tools shows both host names (or 3 if I have also added a manual one as well).
Summarizing your request with less words
Hmm, that's an interesting idea. Currently, Pi-hole seems to favor the host name pulled from the upstream server. Only if this doesn't lead to a result, go and ask the database. You request the inverse, right? First check the database and only if there is nothing here, go and ask the upstream.
I can see this being dangerous as there would be no way how the database host name could be updated in this case (at least no other way next to editing the database which may be dangerous for the unexperienced).
This request seems to be separate from the new feature described in here. If my interpretation is correct (@Robert_D_Marriott please let us know), then you are asking for a different priority of the name sources.
How many IP addresses are listed for this client? The ony you want may currently be at position 1, however, this is arbitrary and when you change the sorting of the table, another one (I guess this will be the ISP provided you DONT want to see) will be at the top. How would you pick which one to show?
Two thoughts based on your response. 1. There is an already a concatenated field of all the host names in the network table under tools. If there was a choice to select the concatenated host names field to show all like it is in the network table, that may not be a terrible option (but a challenge for space). 2. I have a few clients with north of 5 IPv6 addresses from the last couple of days but only one IPv4. Only one is technically current. In most cases, it is only 2 IPv6 and then the IPv4. I haven't tracked down yet why its updating quite so often, because that seems excessive.
Suspected: Either your ISP is doing this (it shouldn't) or you are using the IPv6 privacy extension (you shouldn't (typically)).
Looking into the data, this concatenated field is just how they present it. In the database, each host name is stored under an IP address. And there is an IP address -> MAC address link. Hence, host names are only weakly correlated to MAC addresses.
Let's see what they come up with. It may not look like one, but I find this a very challenging issue because FTL precomputes all the statistics for the individual clients so this seems to complicate things tremendously when you allow them to appear grouped. Definitely something for another discussion.