db: Update database models for compatibility with 2.0.12 / HEAD #9

tuxuser · 2022-01-29T21:00:23Z

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.

alixinne · 2022-01-30T19:00:40Z

src/models/global.rs

    #[validate(range(min = 10))]
    pub width: u32,
    #[validate(range(min = 10))]
    pub height: u32,
+    pub fps: u32,
+    pub framerates: String,


This looks like it's a list of framerates, maybe it should be a Vec<u32>? Do we have a spec/schema for this somewhere?

alixinne · 2022-01-30T19:01:14Z

src/models/global.rs

+    pub fps: u32,
+    pub framerates: String,
+    pub input: u32,
+    pub resolutions: String,


Same as for framerates, this looks like a list, maybe it should be a Vec with Resolution suitably defined?

src/models/global.rs

alixinne · 2022-01-30T19:03:53Z

src/models/global.rs

+    pub available_devices: String,
+    pub device: String,
+    #[serde(rename = "device_inputs")]
+    pub device_inputs: String,


Same as below, this should be a list if it's a list of devices, not a String

src/models/global.rs

src/models/instance.rs

tuxuser · 2022-01-30T22:02:17Z

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

src/models/global.rs

alixinne · 2022-01-30T23:13:46Z

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 · 2022-02-05T13:02:51Z

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

…es (fixes issue alixinne#5)

Deserializes string value into Option<String> -> `None` if string is "None" (case-insensitive check) else `Some(str)`

alixinne · 2022-02-14T23:02:47Z

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 · 2022-02-21T21:31:43Z

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 · 2022-02-23T18:07:53Z

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 · 2022-02-23T22:09:51Z

~~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...

…tring