Opened 11 years ago
Closed 8 years ago
Last modified 6 years ago
#11386 closed Patch - Feature (fixed)
Patch: Let Services API clients check MythTV's ability to transcode
Reported by: | Owned by: | Bill Meek | |
---|---|---|---|
Priority: | minor | Milestone: | 0.28 |
Component: | MythTV - Services API - Backend | Version: | Master Head |
Severity: | medium | Keywords: | Services API |
Cc: | Ticket locked: | no |
Description
This patch gives a Services API client the ability to detect backend configuration options that would prevent the client from being able to transcode recordings.
The client can then tell the user where the problem(s) are and refuse to run until they've been resolved.
Four items are addressed, based on the the experience of one client's users. The framework for additional checks is added.
- Not compiling with --enable-libx264 isn't easily diagnosable.
The client only knows that transcoding has started, but, if it fails, the reason can't be displayed to the user. mythbackend --version doesn't display an entry such as: using_libx264.
- If --disable-libdns-sd was used, mDNS won't be available.
This assumes that a client allows manual backend IP configuration and wants to alert the user that automatic configuration is available.
- Add run-time logging options.
This allows clients to direct their users to the location of backend log files.
A new GetConfigurationInfo? API command is called like and returns:
http://<BackendServerIP>:6544/Myth/GetConfigurationInfo <ConfigurationInfo version="1.0" serializerVersion="1.1"> <Build> <LibX264>true</LibX264> <LibDNS_SD>true</LibDNS_SD> </Build> <Log> <LogArgs>--verbose general --logpath /var/log/mythtv</LogArgs> </Log> </ConfigurationInfo>
- Detect unreadable/unwritable Storage Groups.
In the case of unwritable Streaming Storage Groups, the mythtranscode program will fail and the client will not know why. Granted, users should see BE log info if an unwritable Storage Group is added, or when mythbackend starts. mythtranscode only logs the following when it can't write to a Streaming Storage Group:
CoreContext transcode.cpp:491 (TranscodeFile) - hls->InitForWrite() failed
I didn't try to address the issue of the Built-In streaming group.
The response to the existing GetStorageGroupDirs? API command is enhanced to return DirPerms? true, only if the directories are readable and writable by the user running the backend:
http://<BackendServerIP>:6544/Myth/GetStorageGroupDirs?GroupName=Streaming <StorageGroupDirList version="1.0" serializerVersion="1.1"> <StorageGroupDirs> <StorageGroupDir> <Id>13</Id> <GroupName>Streaming</GroupName> <HostName>mc1</HostName> <DirName>/var/lib/mythtv/storage/streaming/</DirName> <DirPerms>true</DirPerms> <-------- New </StorageGroupDir> </StorageGroupDirs> </StorageGroupDirList>
Attachments (3)
Change History (12)
Changed 11 years ago by
Attachment: | services-api.v1.patch added |
---|
comment:1 Changed 11 years ago by
Component: | MythTV - General → MythTV - Services API |
---|
comment:2 Changed 10 years ago by
Milestone: | unknown → 0.28 |
---|---|
Owner: | set to stuartm |
Status: | new → accepted |
comment:3 Changed 10 years ago by
Changed 10 years ago by
Attachment: | services-api.v2.patch added |
---|
Built on: v0.28-pre-813-g501de62, adds language tests and SG size (and fixes typo in v1.)
comment:4 Changed 9 years ago by
Bill, I like the ideas. I going to apply them with a couple of changes:
"GetConfigurationInfo?" is too easy to confuse with an endpoint which returns settings information and we already have those. I'm leaning towards "GetSystemInfo?" or "GetBackendInfo?".
For storage group directories I think returning individual booleans for read and write permissions is more useful.
Being able to read but not write to a storage group isn't a fatal issue, it still allows streaming of content.
comment:5 Changed 8 years ago by
A new Qt5 tested patch is almost ready. It includes the GetBackendInfo? and read/write bools suggested in the above comment (just in case someone else is is thinking of working on this too.)
Changed 8 years ago by
Attachment: | services-api.v3.patch added |
---|
Qt5 plus suggestions from comment 2 and env additions
comment:6 Changed 8 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
comment:7 Changed 8 years ago by
Owner: | changed from stuartm to Bill Meek |
---|
comment:9 Changed 6 years ago by
Owner: | changed from Bill Meek to Bill Meek |
---|
The original patch won't apply against the current master. I have a new version ready, however, I'm adding a test to see if $LANG is set. I'll attach it when completed.