...
I've had a peak at the source code of the IceTV plugin that Beyonwiz wrote and it defaults to model id '22' if it can't read the model code from the Beyonwiz firmware or loader (via enigma2 plugin API). As far as I know model id 22 means it's a T3.
That's not my reading of the code. The system default for the config variable config.plugins.icetv.device.type_id is 22, but that's not determined in any way by whether the IceTV plugin can read the machine brand or model from the firmware. There's no way that I know of that the Beyonwiz firmware can fail to retrieve the brand name and model - it's compiled into the main app (functions getMachineBrand() and getMachineName()).
At login time, the Beyonwiz sends the value in config.plugins.icetv.device.type_id to the IceTV server in a login request in the ["device"]["type_id"] entry in the request. When the login response is sent back from the IceTV server, the response's ["device"]["type_id"] is used to set the value of config.plugins.icetv.device.type_id.
The IceTV plugin doesn't explicitly send the PVR's brand/model information in the login request, but it is sent in the "User-Agent" request header of the login request. The login request's ["device"]["label"] defaults to the brand/model string, but that string can be changed by the user in the setup wizard, so it can't be relied on for the model type.
So, in essence: at the initial setup, the Beyonwiz sends ["device"]["type_id"]=22 in its login request, doesn't have a reliable brand/model string in ["device"]["label"], and has the string "SystemPlugins.IceTV/
versionstring (Beyonwiz; T
n)" in the User-Agent field of the request header.
The server appears to ignore the information in the User-Agent string and simply sends back ["device"]["type_id"]=22 as the device type, no matter what the device is. That value is then assigned to the PVR's IceTV type_id config variable.
If the device logs in again, the whole thing repeats.
I'm not saying that the server should use the User-Agent informaton to work out what it should return as ["device"]["type_id"], but it seems to be the only place in the protocol where it can reliably get that information.