Describing the reservation table, and renameing file

This commit is contained in:
Ken Fallon 2024-12-28 12:18:39 +01:00
parent 86a1e7dded
commit 3d7ab52e5b
2 changed files with 62 additions and 18 deletions

View File

@ -1,4 +1,4 @@
# File Structure
# Show Processing
We receive random files from random people on the Internet, so they are treated with extreme care.
@ -25,6 +25,11 @@ The directory structure is based on a combination of fields separated by the und
2339594445_9278_2044-02-24_aeb0579fcac318005d7550a60fd60403676c24d94148b
2339680845_9999_1970-01-01_4bd713699e5bc0978d5fef85a60f09bc7f70ef3488624
```
The upload will produce at a minimum a `shownote.json` file. It may also include a host photo, and usually a media file for the episode. If the media file is not provided, then the Janitors will attempt to download it from the provided `url`. If that is not possible, then the host will be contacted to provide the show, and if they do not or if it will cause a delay, the show slot is freed up for another contributor.
Addition files and images may be provided by the host, eg: images, scripts, pdf documents etc.
Shows destined for the reserve queue are moved from the upload directory and placed in the reserve directory using the script [rename-reserve.bash](https://repo.anhonesthost.net/HPR/hpr-tools/src/branch/main/workflow/rename-reserve.bash).
This is run manually by the Janitors as it checks to see if a url to the show was provided, and attempts to download the linked file. When new hosts submit a show directly to the reserve queue, the Janitors will resubmit it to the first available slot in the normal queue. This is because new hosts need to have an entry created in the `hosts` table, but also because it gives the community an opportunity to welcome the new host.
@ -42,9 +47,7 @@ It renames the directory structure based on a combination of fields separated by
```
Reserve shows are downloaded and submitted by the Janitors on behalf of the host. This follows the normal posting process where the host and Janitors are cc'd on the notification emails. The only difference is that the audio is edited to include a notification that the show is from the reserve queue, and that it is the Janitors that upload the show via the supplied link.
## Show Processing
### Adding the host to the `hosts` table
## Adding the host to the `hosts` table
This is currently added manually by the Janitors, as the text to speech tools often requires manipulation to get it sounding correct.
@ -124,7 +127,14 @@ The duration will be extracted from the media, and the other metadata from the `
The script allows overwriting of any value in the json file from the command line, and also prevents posting from a new host that has not yet been assigned a entry in the `hosts` table.
Once all the checks are done the script will `rsync` the formatted json, the shownotes html file, and any images back to the upload directory.
Once all the checks are done the script will `rsync` the following files back to the upload directory.
- `shownotes_origional.json` the original json file for reference.
- `shownotes.json` the human readable formatted json file.
- `shownotes.html` the extracted and edited show notes.
- `post_show.json` the json file used to create the `eps` table entry.
- Any additional images in the format `hpr${ep_num}_${image_count}.${ext}` and if greater than 400 pixels, then the thumbnail in the format `hpr${ep_num}_${image_count}_tn.${ext}`.
- Any supporting files.
Then it will use the `curl` command to POST the show to [add_show_json.php](https://repo.anhonesthost.net/HPR/hpr_hub/src/branch/main/cms/add_show_json.php).
@ -187,18 +197,7 @@ CREATE TABLE `eps` (
<tbody>
</table>
<!--
## Output Directory Structure
@ -214,7 +213,6 @@ All these are combined and end up as a complete entity, on one of the HPR [Origi
From there is delivered made available via RSS, etc.
<!--
TODO
## Upload

View File

@ -258,3 +258,49 @@ sequenceDiagram
![The email containing the confirmation](email_thank_you_for_uploading.png)
# Storing the reservation in the Database
The HPR Database is used to track the `status` of each show as it is been processed, using a normally hidden table `reservations`. It is not publicly available as it contains the IP address of the host uploading the show as a security measure. Once the show is processed the IP address is removed from the table.
```
--
-- Table structure for table `reservations`
--
DROP TABLE IF EXISTS `reservations`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `reservations` (
`ip` varchar(45) NOT NULL,
`timestamp` datetime NOT NULL,
`key` varchar(46) NOT NULL,
`ep_num` int(5) NOT NULL,
`ep_date` date NOT NULL,
`email` text NOT NULL,
`verified` tinyint(1) NOT NULL DEFAULT 0,
`status` text DEFAULT NULL,
PRIMARY KEY (`key`),
UNIQUE KEY `key` (`key`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_unicode_ci COMMENT='To keep track of reservations';
/*!40101 SET character_set_client = @saved_cs_client */;
```
<table>
<thead>
<tr>
<th>Field</th>
<th>Description</th>
<th>Example</th>
</tr>
</thead>
<tbody>
<tr><th>ip</th><td>IP address of the host uploading the show as a security measure.</td><td>8.8.8.8</td></tr>
<tr><th>timestamp</th><td>The time the reservation was first made.</td><td>2044-02-24 12:34:56.789</td></tr>
<tr><th>key</th><td>The random unique key for this request</td><td>aeb0579fcac318005d7550a60fd60403676c24d94148b</td></tr>
<tr><th>ep_num</th><td>This is the Episode Number that will uniquely identify the show.</td><td>9278</td></tr>
<tr><th>ep_date</th><td>The date the show air, namely when it gets put in the main feed.</td><td>2044-02-24</td></tr>
<tr><th>email</th>The hosts email address with the `@` replaced with `.nospam@nospam.` as an antispam measure<td></td><td>Emperor.Ming.nospam@nospam.example.com</td></tr>
<tr><th>verified</th><td></td><td></td></tr>
<tr><th>status</th><td></td><td></td></tr>
<tbody>
</table>