db: Update database models for compatibility with 2.0.12 / HEAD

[tuxuser]

This change makes hyperion.rs compatible with latest hyperion.ng database, so settings can be imported from hyperion.db and dumped into TOML-representation if desired.

[tuxuser]

When you are suggesting changes from String to Vec<..>, it would need a custom De-/serializer, correct? Looking through the schemas in hyperion.ng they list the mentioned fields as "String".

That are:

• framegrabber->available_devices
• framegrabber->device_inputs
• framegrabber->framerates
• framegrabber->resolutions

Here's the schemas btw: https://github.com/hyperion-project/hyperion.ng/tree/master/libsrc/hyperion/schema

[alixinne]

When you are suggesting changes from String to Vec<..>, it would need a custom De-/serializer, correct? Looking through the schemas in hyperion.ng they list the mentioned fields as "String".

That are:

* framegrabber->available_devices

* framegrabber->device_inputs

* framegrabber->framerates

* framegrabber->resolutions

Here's the schemas btw: https://github.com/hyperion-project/hyperion.ng/tree/master/libsrc/hyperion/schema

Yes, I think we need (at least) a custom deserializer, maybe a serializer if we intend to write back to the database. I had a look at the schema and it does say string, but parts of the JS code for the UI seem to treat this as some kind of list? e.g. https://github.com/hyperion-project/hyperion.ng/blob/2f573a117feb34d2c0de6143b0c49466622b45f8/assets/webconfig/js/content_grabber.js#L288

To give more context on the config loading, I went with the "make the parsing as strict as possible", so we only have to do the hard reverse engineering work once, and then the rest of the engine has ready-to-use explicit values (hence the enums, Options, etc. which are not present in the original schema).

[tuxuser]

Did not have the time yet to look into those pseudo-list config options ..

[alixinne]

So here's what I gathered from a fresh 2.0.12 install:

 {
  "available_devices": "UVC Camera (046d:0825)",
  "blueSignalThreshold": 0,
  "cecDetection": false,
  "cropBottom": 0,
  "cropLeft": 0,
  "cropRight": 0,
  "cropTop": 0,
  "device": "/dev/video1",
  "device_inputs": "0",
  "enable": true,
  "encoding": "YUYV",
  "flip": "NO_CHANGE",
  "fps": 15,
  "fpsSoftwareDecimation": 0,
  "framerates": "15",
  "greenSignalThreshold": 100,
  "hardware_brightness": 128,
  "hardware_contrast": 32,
  "hardware_hue": 0,
  "hardware_saturation": 32,
  "height": 480,
  "input": 0,
  "noSignalCounterThreshold": 200,
  "redSignalThreshold": 0,
  "resolutions": "8",
  "sDHOffsetMax": 0.46,
  "sDHOffsetMin": 0.4,
  "sDVOffsetMax": 0.9,
  "sDVOffsetMin": 0.1,
  "signalDetection": false,
  "sizeDecimation": 8,
  "standard": "NONE",
  "width": 640
}

It seems that even though the field names are plural, they only represent a single value in the UI (there's only one of each capture device type selected for any single instance), so they're not lists, and their type is as follows:

• available_devices: String, friendly device name
• device_inputs: usize (but stored as a String, needs parsing), index into the list of known V4L2 devices?
• framerates: u32 (but stored as a String, needs parsing), number of frames per second, matches what's in the fps field
• resolutions: usize (but stored as a String, needs parsing), index into the list of resolutions supported by the V4L2 device. The actual resolution is given by width and height

[tuxuser]

Thx for posting the json representation of the config section in question.

For the deserialization FromStr and serialization fmt::Display an additional dependency could be pulled in: https://crates.io/crates/serde_with

#[serde_as]
#[derive(Deserialize, Serialize)]
struct Foo {
    // Serialize with Display, deserialize with FromStr
    #[serde_as(as = "DisplayFromStr")]
    bar: u8,
}

[alixinne]

Thx for posting the json representation of the config section in question.

For the deserialization FromStr and serialization fmt::Display an additional dependency could be pulled in: https://crates.io/crates/serde_with

#[serde_as]
#[derive(Deserialize, Serialize)]
struct Foo {
    // Serialize with Display, deserialize with FromStr
    #[serde_as(as = "DisplayFromStr")]
    bar: u8,
}

Good idea, I wasn't aware of serde_with, it makes sense for these.

[tuxuser]

Framegrabber seems like the base struct and GrabberV4L2 derives from it. The json you posted has fields from GrabberV4L2.

Now, to keep code duplication at a minimum, shall we pull in Framebuffer into GrabberV4L2 via serde-flatten ?

Incorrect, V4L2 does not inherit all the fields from Framebuffer... annoying! So it needs fields re-defined...