yeah, scroll up a bit. @coolmaui pointed me in the right direction.
the XMLTV format was never an issue. i had been using that while developing my own parser. the part i missed was that they had the code for the grabbers up there too. i don't know how much they would have helped me, as it was pretty easy to just pick apart the json itself and apply it to the XMLTV output, but definitely could be helpful to someone else trying to do this if they have perl experience.
New in v2020.12.10.0059
will that work with any duration or only an hour?
Why would it be a parameter if it only worked with one value? 
i figured that was the answer, just wanted to make sure 
Much better than “?givemeanhourofxml=1”. 
Well, considering the /devices/…/guide endpoint is already accepting the duration parameter from Channels' own native clients, it makes sense that the /devices/…/guide/xmltv endpoint would accept the same parameters.
Both endpoints also take a time= parameter which accepts a unix timestamp
This is a great feature.
I must be doing something wrong though. I am only getting listings for the first few channels. What am I missing?
Changing /ANY/ - to a specific device/source seems to be working as I would expect.
Edit: Maybe not. I am only seeing data for up to channel 7.1 on each of my HDHR tuners. TVE seems to be working as expected.
It looks like to me the practical limit on this (at least running Channels on a Pi4) is about a day's worth of data. I tried loading three days of data, and the connection timed out.
I use Channels as a source for NextPVR (so I can get my TVE channels into NextPVR), and right now I just use Schedules Direct for the data on those channels. It works, but if I import a new Channel into NextPVR then I have to reset all the guide data mapping. And I have to have a combination of east coast and west coast SD sources to deal with feeds that are for time zones I'm not in. I was hoping to use the XMLTV feed to replace the SD stuff (as that doesn't get overwritten when I update channels), but that won't work for me if I can only get a day of data. Ideally I'd be able to get 14 days to match what I get from SD.
I believe Channels' own clients request the guide data in 6 hour chunks. (Although, I could be mistaken and it might be 4, 8, or 12 hours. In any case, each grab is less than a day.) As Aman mentioned, use the duration parameter in conjunction with the time parameter.
(The date command can be your friend for converting human-readable dates into epoch time. For example, to retrieve a 6 hour chunk of data beginning on Friday at 9:00 am:
curl -sSL "http://${DVR}:8089/devices/ANY/guide/xmltv?time=$(date -d 'Friday 9:00 am' +%s)&duration=21600" > guide.xml
where DVR is the IP address of your DVR server.)
I used a duration of 1209600 for 14 days, and worked fine for me.
Hmmm. Looks like some odd Firefox issue. If I use the mDNS name for my Channels setup (channels.local) with the URL and 14 days of data it works. If I use the IP address, it times out. IP address works fine in Microsoft Edge. So I guess I can do what I want. Just need to find time to make the changes.
If we have multiple M3U sources defined are we supposed to be able to get the XMLTV output for each source separately?
I am using:
http://x.x.x.x:8089/devices/M3U-source2/guide/xmltv?duration=604800
The output is valid and contains data but for all M3U sources.
Thank You
I am still seeing this and it is frustrating for what I am doing. The extra guide data confounds and confuses downstream processes to which I export the data. Did you ever get an answer? My short-term approach was to delete the second M3U tuner, as it has issues right now.
I'm also still seeing this.
The output includes listings for all of your source devices using lineupId "X-M3U".
The unwanted source device listings <channel> doesn't contain <display-name>Channel Name</display-name>, just Channel Numbers <lcn>.
You can see the same issue in the json output /devices/<DeviceID>/guide
I'd love to help contribute to this to get Peacock/Amazon/MountainWest to work