41 |
42 |
43 |
44 |
45 |
46 | | HTTP Method | 19 |Path | 20 |Handler | 21 |
|---|---|---|
| {{ .Method }} | 27 |{{ .Path }} | 28 |{{ .Handler }} | 29 |
| Id | 64 |Station Id | 65 |Channel Number | 66 |Channel Name | 67 |Stream Location | 68 |Group | 69 |Logo | 70 |Action | 71 |Toggle | 72 |
|---|---|---|---|---|---|---|---|---|
| {{ .Id }} | 78 |{{ .StationId }} | 79 |{{ .ChannelNumber }} | 80 |{{ .ChannelName }} | 81 |{{ .StreamURL }} | 82 |{{ .Group }} | 83 |{{ .Logo }} | 84 |85 | 86 | | 87 |88 | 89 | | 90 |
Total Channels: {{ len .entries }}
104 | 105 | 106 | 107 | 174 | 175 | 176 | -------------------------------------------------------------------------------- /scripts/chromecast/pbs/README.txt: -------------------------------------------------------------------------------- 1 | Tunes live TV in the PBS app. 2 | 3 | * PBS STREAMING INFRASTRUCTURE 4 | 5 | Most PBS affiliates use the streaming platform operated by the 6 | national PBS umbrella organization, and that's what the PBS app 7 | is for. I think there are a few PBS affiliates that use some 8 | different infrastructure for streaming, and you won't be able 9 | to use the PBS app and these scripts for those affiliates. 10 | 11 | The scripts here are aimed at navigating to a PBS affiliate's 12 | live stream. They don't know anything about on-demand programming, 13 | even though it is available in the same PBS app. 14 | 15 | * SCRIPTS STRUCTURE AND CONFIGURATION 16 | 17 | Our caller, ah4c, expects there to exist 3 scripts: "prebmitune.sh", 18 | "bmitune.sh", and "stopbmitune.sh". For this set of scripts, there are 19 | several common definitions, functions, etc. Each of the expected 20 | scripts is a trivial 3-liner that sources "common.sh" and then calls 21 | the applicable function defined within "common.sh". The intent of that 22 | arrangement is to achive more consistent naming, simpler editing, and 23 | so on. 24 | 25 | At the top of "common.sh" is a collection of variables whose names 26 | start with "CONFIG_". As you might guess, those are things that 27 | conditionally control aspects of the scripts behaviors. If you are 28 | happy with the default values defined in "common.sh", then that's all 29 | you need to know. If you want to change any of them, you can, of 30 | course, just modify "common.sh". A better way is to create a file in 31 | this same directory called "config-local.sh" and provide modified 32 | values for just the items of interest. Copy/paste/modify is the most 33 | reliable way of doing that. The advantage of using "config-local.sh" 34 | is that your changes would not be overwritten by any updates to this 35 | set of scripts. If you don't want to modify any config values, it is 36 | not necessary to create "config-local.sh" at all. 37 | 38 | * TUNING AND STATION SELECTION 39 | 40 | The channel tuning info (the final part of the URLs in the m3u) can be 41 | one of two forms: 42 | 43 | "Waaa" 44 | or 45 | "Waaa_12345_2". 46 | 47 | In both cases, the tag "Waaa" (or whatever) is ignored. It's just 48 | documentation for you, our dear user. Station call sign or marketing 49 | names are good choices. For the second form, the separator character 50 | is underscore, so don't include any underscores in the tag. For URL 51 | reasons, don't include any slashes or spaces or other URL unsafe 52 | characters in any part of the channel tuning info. 53 | 54 | For the first form, live TV is selected with whatever local PBS 55 | channel you have last configured in the app. This is most useful for 56 | the majority of places which are only served by a single PBS affiliate 57 | (or if you only ever watch a single affiliate). 58 | 59 | The second form has a ZIP code used to populate the app's search box 60 | for stations. The last number is a one-based position in the results 61 | list. I'm hoping the results always come back in the same order, but I 62 | have no way to verify that. This is most useful for places served by 2 63 | or more PBS affiliates. There are many places with 2 and a few places 64 | with 3. I don't know if there are any places with more than 3. 65 | 66 | For example, in the Seattle and Tacoma, Washington, area, there are 2 67 | PBS affiliates. If you search for a Seattle area ZIP code, you get 2 68 | results back. So far, I've always seen them come back as KCTS (the 69 | Seattle affiliate) first and KBTC (the Tacoma affiliate) second. You 70 | select which one you want with either "_1" or "_2". You can see this 71 | in the sample M3U pbs-seatac.m3u. There's another example M3U, 72 | pbs-worcester.m3u, for a ZIP code in Worcester, Massachusetts. That 73 | ZIP code search offers a choice of 3 PBS affiliates. 74 | 75 | The tuning script remembers the last station it tuned, so it only goes 76 | through the station search dialog if it needs to change to a different 77 | PBS affiliate (or if a lot of time has passed). 78 | 79 | NOTE: Although the search for affiliates is based on the ZIP code 80 | entered in the search box, the PBS streaming platform does geographic 81 | restrictions based on the source IP address it sees. That's why you 82 | can't watch out-of-area PBS programming. The PBS app will let you 83 | search for any ZIP code and will display the results. Selecting an 84 | out-of-area PBS affiliate in the search results will give an error 85 | message. The code in these scripts doesn't have a way of knowing that 86 | and assumes the station selection went correctly. There's also a small 87 | chance that your ISP's location will be different from your location 88 | for the purposes of PBS restrctions. If you can select it manually in 89 | the PBS app, the scripts can select it. 90 | 91 | * DELAYS 92 | 93 | The scripts work mostly by doing what's called "remote emulation". 94 | That is, they use adb commands to simulate button presses on a remote 95 | control. When a human operates the remote, it's obvious when they can 96 | press more buttons. The scripts mostly don't know when a reaction has 97 | happened on the screen, so they resort to a bunch of fixed delays to 98 | wait until the right time for the next thing. Those delays are a bit 99 | fiddly and depend on your specific equipment, what your equipment is 100 | doing at the moment, and, in some cases, the response time to network 101 | requests over the internet. Phase of the moon might be in there 102 | somewhere. 103 | 104 | Delays are expressed in seconds and need not be limited to whole 105 | numbers. Decimal fraction amounts are acceptable, e.g., "1.345". 106 | 107 | Instead of calling sleep directly, the scripts use the "settle" 108 | function (defined in "common.sh") which scales how much they 109 | sleep. When called, that function alters the requested sleep duration 110 | according to CONFIG_DELAY_SCALING and CONFIG_DELAY_OFFSET. If the 111 | scaling is 1 and the offset is 0 (the defaults), you get exactly the 112 | sleep durations coded into the scripts. If you need proportionally 113 | longer delays, increase the scaling. If you want proportionally 114 | shorter delays, decrease the scaling. If you want to add (or 115 | subtract) a fixed amount to each delay, set the offset to that amount. 116 | If you configure the scaling and offset values to 0, sleep becomes a 117 | no-op (which probably will not be a good choice). 118 | 119 | There are CONFIG_ items for each individual delay. Instead of scaling 120 | or offsetting them across the board, you can adjust them individually. 121 | 122 | The advantage of long delays is that you can be sure your device has 123 | finished reacting to inputs before the script moves on to the next 124 | thing. 125 | 126 | The disadvantage of having overly long delays is that you risk losing 127 | the beginning of real programming. For example, if you are recording a 128 | 30 minute program and you have 1 minute worth of delays, then the 129 | first minute of the recording will be showing this tuning noise 130 | instead of the first minute of the real program. For PBS shows, that 131 | usually doesn't matter since they tend to thank sponsors at the 132 | beginning and sometimes show a preview of the show. However, it's best 133 | to not rely on that and have the delays as short as you can and still 134 | have them tune reliably. Timing is trickiest if you have multiple PBS 135 | affiliates and need to change your local station before recording. 136 | 137 | In my environment, with the default delays, it takes about 30 seconds 138 | to tune when a station change is required. It takes about 12 seconds 139 | when a channel change is not required. Tested on Google Chromecast HD, 140 | Tivo Stream 4k, and Onn 2k Stick. I also tested against a fairly old 141 | Amazon Fire TV stick, though I had to scale the delays a bit for that 142 | to work. 143 | --------------------------------------------------------------------------------