Hardware mismatch error and other questions

That means a third one registred, when you reinstalled linux. Hardware id is based on a unique id, but no problem you should be able to use when the new will replace the old, if you keep using 2 only. If you in a rush contact authors, i do not have access.

license stuff is still in in development but you should still have acces via 2 pc
u can try A force a license update(I am not sure if this forces a machine update also).

license file is created when you run wg++, it records the license (in linux) in /home/user/.local/share/WebGrab+Plus/License/wglocal.lic but obviously it belongs to that hardware so if you move it on another pc won't work. Wg creates that files every run, so If you delete it will be recreated. Now looks like you using one only...

I think we shud call ripleys believe it or not.
lol
yes it does seem weird ur Linux machine is producing diff hw ids.
I may have to go find my intel ncu as I was using mint 18.3 on it before I put it away.

I've hit the same issue. I wonder if it's because I use docker on Ubuntu, which has been updated 3 times + restarted etc.
An update will recreate the image, therefore the whole /use/share etc will be new.
Now I only have 1 pc with this on, run through command line & have not changed any hardware. But my thinking is docker + Linux is causing and issue.
I've added the F (to pay respects :) ) to the license config and that has allowed me to run it.

Am I ok to leave this in to force an update each time?
Thanks

Hi,

i have hit the 2 computer limit (hardware mismatch) and wondering how i remove one of the computers as it died on me and i have had to replace it and now cannot get it to run as its looking for the old computer?

And help appreciated.

Jamie

Hi guys,

I have same problem on my raspberry pi, yesterday was working today I have HW mismatch detected. I use also WG++ on my Windows PC for testing purposes (and there is working normally), so 2 machine total. I tried with forcing license didn't work.

BR,
Igor

strange, if you have mismatch, it should set (the 2 you use) in 24 hours anyway. If you keep getting error send a note to authors.

Thx for reply, I will send email to Jan, just to understand the root of the problem. Have a nice evening.

This Hardware mismatch error is really annoying. I'm running wg+ inside a docker image and getting this error way too often. Is there something I can do to help fixing this definitly ?

This is happening every day for me. I have to run my old 2.1.9 in Docker in the meantime, especially if the Docker container is stopped and started it will generate a new HWID. My cronjob does this. I cannot afford to let my container running 24 hours :-(.

you should be asking the creator of docker about this.your actual hardware doesnt change to why does the hwid change everytime its launched.

you could also use the h option on your wg lisence line in your webgrab config.xml as descrived above.
this put unnecessary burden on the server but for now until another solution is figured out it may be your only option for docker users.

@Blackbear, the problem here in Docker is that it is not tied to a unique hardware signature, unlike running it directly in a server. This applies to all running Docker containers and not only running wg++ in Docker.

Having said that, I think this is just a disadvantage of wg++, and you cannot run it in containers. This makes the 2 hardware limit is so strange that I can't even use version 3.0++ at all.

use the h option,this will force a hwid update everytime webgrab runs(inside docker) and u will have you donator limits.
its not ideal as i said above but there isnt that many docker users so it should be fine.

normally the h option would be used for linux or windows users when they install webgrab on a new/different pc.
the h update would only need to be run once as the hwid never changes.

as u know docker is a different beast.

hy guys, regarding to this discusion i have the same problem diferent situation, new vps unbuntu 18
firstime run wg++ is not working at all

Debug ]
[ Debug ] Running on: Unix 4.15.0.118
[ Debug ] Environment: 4.0.30319.42000
[ Debug ] Mono version: 4.6.2 (Debian 4.6.2.7+dfsg-1ubuntu1)
[ Debug ]
[ Debug ] Loading timezone data
[ Debug ] Embedded timezones source: timezone.timezonesdata.txt
[ Debug ] Reading config file: /root/.wg++/WebGrab++.config.xml
[ Info ] Checking License ..
[ Info ] For License request/update data, see WGLicense.log.txt
[Warning ]
[ Info ] Hardware mismatch detected .. see WGLicense.log.txt for details
[Warning ] Program will close ..

Hi, I'm same boat with this issue, please check my account, thanks.

running force licence with option f or h should fix it

mat8861 wrote:

running force licence with option f or h should fix it

I tried with “f” or “h” many times but not success. I change webgrab from old pc to new pc and get this error

Very strange, i informed the authors
Edit:
It has benn reset, it looks like you changed 5 times hwid.

I Have docker and tried with f and h it is not working, to whom i have to send, to check my account msallal

Hi Blackbear199

I've started experimenting with webgrabplus and docker, docker containers are transient and updated often either due to underlying package updates in the base image or due to updates from the upstream application, it appears as though each image/container update triggers the underlying webgrabplus licence check to believe that there has been an underlying hardware change. I can't comment on why as I'm not privy to how webgrabplus checks the hardware, for the purposes of this issue it's probably easiest to think as docker containers as transient short lived operating system installs.

There have been a few workarounds suggested none of which are perfect:

Using the "f" or "h" flag to force licence checks has been tried here:

https://github.com/linuxserver/docker-webgrabplus/issues/26#issuecomment... and from a container perspective "h" would be preferable as that wouldn't require the underlying .lic file would need to be deleted before the cron job is run.

Trying both the methods above works for the first time a container is created but it fails if the container is recreated or there's a version change.

The big issue is after the "h" or "f" flag is set after webgrab runs it then updates the underlying .xml file to replace the previously set "h" or "f" flag with "To force a license update; replace this text with the letter f" thereby getting us back to square one.

I'm wondering if there's anyway we can modify the behaviour of webgrabplus to avoid changing the .xml perhaps with a flag at runtime which could be applied to the docker container so that other operating systems aren't also performing more frequent license checks?

One other option is now I hopefully have outlined the issue a little more that youu may be able to utilise the hardware id check routine differently to account for the above behaviour.

The only other alternative I can think of is some modification of the underlying docker image to either "sed" the "To force a license update; replace this text with the letter f" with either a "h" or "f" or alternatively delete the ".lic" file via cron before the running of the webgrab routine.

I guess any of these solutions would work, but the net effect to webgrabplus would be the same which is users utilising docker would be performing license updates more often.

Happy to discuss this more if you feel I can clear things up any more.

Scope of license: License check is made to avoid multiple hardware id run (despite license default is set to 2 hwid's).
Cause of Problem: docker every reboot recreates a new hardware id (uuid), which make license check to fail.
Solution: update h is a very temporay solution, it reset license and sends new hardware id, that works within a certain time frame.
Final solution: I think that besides manipulating the license or xml, you should find the way to set a permanent Hardware id (uuid) within docker. That is composed by cpu/hard disk/network address mainly.
If you google on how to set a permanent uuid in docker there are several suggestions
https://forum.syncthing.net/t/docker-new-device-id-when-container-is-res...
I remember someone in forum succeed setting uid and gid to 100/1000.
May be BB has more suggestions

Hi mat8861

I'm familiar with docker & linux, (although I have limited Windows experience) and for the most part I agree with your assessment, however that link you've suggested is regarding user and group ids and access to the underlying file system, so I don't think this is relevant as UUID generally referring to a unique identifier of disk storage devices in Linux.

The docker image already has mechanisms in place for this and my UID/GID are set and unchanged between container restarts/recreates.

I've managed to implement a workaround at the moment using "h" but could easily adapt that to use "f" instead, although that would also involve removing the license file, but I am conscious that either of these are going to cause some calls to the webgrabplus server for license checks and as you've alluded to may not be a good long term solution.

If I knew what the mechanism for assessing hardware id in webgrabplus is I'm happy to try and pass that through to the container

There are some unique identifiers in memory which are identical regardless of whether you access them from the host or from within the container.

root@ec88e69c23a1:/# cat /sys/class/dmi/id/board_serial
ZM1xxxxxxxxx

root@host:~# cat /sys/class/dmi/id/board_serial
ZM1xxxxxxxxx

root@ec88e69c23a1:/# cat /sys/class/dmi/id/product_uuid
00000000-0000-0000-0000-acxxxxxxxxxx

root@host:~# cat /sys/class/dmi/id/product_uuid
00000000-0000-0000-0000-acxxxxxxxxxx

Bottom line I think the ideal, and technically the most correct solution would be for webgrabplus on a Linux host to use a UUID parameter that is identical either when accessed from the host or from within a container environment.

Currently my hypothesis is that it's using an identifier from the storage/file layer which in docker will change frequently, I suppose the other option is it's parsing a network parameter.

Tell you the true don't remember, we did some tests years ago, windows and linux. I am pretty sure the mac address is one factor, if i am not wrong also cpuid. My suggestion is to contact the author (Jan) and ask him exactly which uid's are used, then work on the docker to see if it is possible to somehow maintain those factors the same after docker reboot/restart.
I mentioned him what we discussing.

Thanks mat8861, interestingly enough I've been experimenting with things to see if I can get to the root of the issue, and currently my working hypothesis is indeed something derived from the MAC address, still testing but it does appear that if I run the container using the host network mode I don't get any hardware mismatch errors, which would fit with what you've just said that the MAC address is a component of this as in the docker host network mode it essentially removes the docker networking abstraction and uses the host machine networking.

It's a little less than ideal as there are some security implications for this and for many of my containers it wouldn't be an option as it breaks a lot of the docker networking features I utilise but for webgrabplus which runs essentially in isolation and just outputs a guide.xml file I'm happy to settle with that.

The other option I could leverage if it is indeed tied to the MAC address is to set a MAC address as static, the downside of this is that as far as I'm aware docker does not check if manually specified MAC addresses are unique so it raises the possibility of MAC address duplication in a multi-container environment.

Using host networking:

version: '3.8'

services:
webgrabplus:
container_name: webgrabplus
network_mode: host
environment:
- TZ=${TZ}
- HOST_OS=${HOST_OS}
- PUID=${PUID}
- PGID=${PGID}
volumes:
- ${CONFIG}/webgrabplus:/config
- ${CONFIG}/webgrabplus/epg:/data
image: lscr.io/linuxserver/webgrabplus
restart: unless-stopped

Using a set mac_address:

version: '3.8'

services:
webgrabplus:
container_name: webgrabplus
mac_address: 02:42:ac:11:65:43
environment:
- TZ=${TZ}
- HOST_OS=${HOST_OS}
- PUID=${PUID}
- PGID=${PGID}
volumes:
- ${CONFIG}/webgrabplus:/config
- ${CONFIG}/webgrabplus/epg:/data
image: lscr.io/linuxserver/webgrabplus
restart: unless-stopped

i dont know much about docker and its inner workings.
i just recently started messing with it as my nas manufacturer had no installer for it so i ended creating my own installer.
seems to run fine and installed portainer to test but havnt gotten around to doing much more than this.

i think the issue with webgrab and docker is this..

it doesnt know or care its being run in a container or a normal linux/windows environment.
its using the givin info like the mac/cpuid or whatever it uses to create a unique hwid it registers when first run.
for some reason i think the username is also used(dont qoute me on this but i thought the creator mentioned it one time).

Actually Blackbear199 that's quite useful, I'm still spinning up containers here and trying to establish what works and what doesn't, and I dismissed it earlier when mat8861 mentioned it, but just found something interesting.

The docker container uses s6-init and implements UID/GID mainly to enable file system permissions on the host mapped folders. In the linuxserver containers that user is abc (the name is unimportant as it's just a placeholder in essence) however if you open a bash terminal up in the container then you essentially elevate to root.

I think I just found a failure case which is if I create the container and perform the initial update manually from a terminal and hence running as root it fails the license check, however if I let the cron job in the container run the initial update (which is run as abc:abc (corresponding to UID:GID) then it works and running a subsequent manual job as root also works.

I'm not entirely sure I've got the conclusion and sequence of the above correct but it would explain the phenomenon I think I witnessed.

So in summary, thus far we have mac address and possibly UID/GID as factors in generating the license.

Essentially once I know the factors used in generating the licence it should be possible to nail down a solid working docker implementation.

As an aside, having been using docker since I think 2015, I'd steer clear of portainer. My vote goes for docker-compose and a yaml file, I've found it easily the best way to configure my containers despite trying all the GUI solutions out there.

totally agree with your last statement.
docker-compose is the way togo.
as i said it was a quick easy way to test the installation.
other than opening and trying the web gui with portainer i did nothing.

from the creator..

the hwid check requires to have a full match of computer name and computer username and at least one 'network related' mac address.
Example .. yours (for linux) was/is :
Primary hardware_id root#xxx/xxxx/xxxx/
That is probably from some time ago . Was that docker??

so in short,clone pc username.

Thanks for getting back to me, I think there are three things that need to align for this to remove the issues with hardware checking in a containerised environment.

A consistent MAC address - This can be accomplished in docker by running the container as "host"

A consistent hostname - this I believe is already covered in the linuxserver readme as container_name and hostname I believe are analogous in docker-compose, and I would assume in docker as well. (So I didn't encounter this as by default I give my containers names)

A consistent user is required. Again as the update process is run by cron as the abc user this should be covered, (abc:abc being a pseudonym for whatever UID:GID the user sets in their docker configuration. However if someone were to try and run the update manually with something like:

docker exec webgrabplus /defaults/update.sh

that would be run as root, effectively a different user, this can be mitigated by a note in the docker readme explaining best practice would be to run this process as the abc user with:

docker exec --user abc webgrabplus /defaults/update.sh

Thanks Blackbear and Mat, hopefully this will clear up the recurring issues with queries both here and in the docker repository about hardware id mismatches and avoid a hacky workaround in the container environment to force hardware updates prior to each run.

Spoken to the linuxserver team, their verdict is that it's best not to use host mode, and, I can see their reasoning. So for anyone finding this in the future these would be recommended docker run commands and docker-compose.yml configs.

docker run -d \
--name=webgrabplus \
--mac-address=00:00:00:00:00:00 \
--hostname=webgrabplus \
-e PUID=1000 \
-e PGID=1000 \
-e TZ=Europe/London \
-v /path/to/config:/config \
-v /path/to/data:/data \
--restart unless-stopped \
lscr.io/linuxserver/webgrabplus

---
version: "2.1"
services:
webgrabplus:
container_name: webgrabplus
mac_address: 00:00:00:00:00:00
hostname: webgrabplus
environment:
- PUID=1000
- PGID=1000
- TZ=Europe/London
volumes:
- /path/to/config:/config
- /path/to/data:/data
restart: unless-stopped
image: lscr.io/linuxserver/webgrabplus

Obviously a valid MAC address will need to be supplied.

The user is static within the docker environment as abc, but if you trigger a manual update then it would be advisable to do so as the abc user utilising the command:

docker exec --user abc webgrabplus /defaults/update.sh

Hopefully this should reduce the confusion both here and on the linuxserver repository regarding hardware mismatchs and avoid forcing licence checks on the webgrabplus servers.

thanks for the info,we get docker related quest about this all the time.
this should help clarify things.