Copy that. I stand corrected. That was my misinterpretation.
Announcing Broadcastify Calls Developer Incentives
- Thread starter blantonl
- Start date
- Status
As best I can tell from the github traffic here, it looks like the lead dev is on board. That was a lot of wasted energy all around
Andy
It really depends. The short answer is no - from the broadcaster's point of view, unless you dive into some very technical details, you'll have to pick one or the other. I wouldn't recommend abandoning one of your existing legacy feeds to do this yet, until we have the solutions in place to provide legacy feeds directly from our broadcastfiy calls implementation. That is in development and will be handled on our end.
I'd just keep doing what you are doing unless you want to stand up a separate trunk-recorder instance.
Exactly, if you read through that - completely above the board, ethical, and I made sure everyone's a winner. Open and honest about intentions. Didn't attempt to bully or stomp on anyone. Participated in the open source process with natural progression and in a collaborative manner.As best I can tell from the github traffic here, it looks like the lead dev is on board. That was a lot of wasted energy all around
Andy
I'm not sure I follow...I'm currently using trunk-recorder to stream selected talkgroups to a traditional Broadcastify feed while still uploading to OpenMHz at the same time from the same instance. This does take some setup that's a bit of a pain though...is that why you're advising against it, since it may not be worth the effort if you'll be rolling out something that will make it unnecessary in the not too distant future?
If you are already an experienced trunk-recorder user, the setup is easy.
I'm not in a position (yet) to provide hand holding for trunk-recorder just yet, I'm getting there. Need to shake out the edge-cases and stubling blocks experienced people are running in to before I move to others.
For you, just compile the latest version of trunk-recorder, and fill in the 3 config options outlined here and you'll be set. You'll need to contact support for an API key and system entry. It will run alongside your custom script for liquidsoap and openMHZ.
Broadcastify-Calls-Trunk-Recorder - The RadioReference Wiki
Quick question, when I setup my trunk recorder feed last week, I used the instructions where the encoding and upload was all in a script using ffmpeg, etc. It looks like the instructions in the link above now say to put the API key and server directly into the config.json and it will use that info to upload directly. Is that the preferable method instead of the script/ffmpeg method?
The project is moving fast, I guess I better be sure to keep up!
Thanks.
The project is moving fast, I guess I better be sure to keep up!
Thanks.
My original intent was to change my hardware scanner over to Trunk Recorder, because I thought the call queuing system was great - no more stepped on calls. As I said, I didnt even know about the new Calls system until Saturday. I still want to upgrade my legacy feed to stream from Trunk Recorder, but I also want to be an ingest provider too. If I have to choose I'd definitely just keep the hardware feed running alongside the ingest until that's sorted out. I'd probably need at least a little bit of hand holding to get a more complicated setup figured out because my linux-fu is not as strong as it should be lol.
It’s up to you.
If you want to pull down the latest version of trunk recorder and follow those new setup instructions here go for it. Either way you should be fine. Broadcastify-Calls-Trunk-Recorder - The RadioReference Wiki
@blantonl Hey I really like that. I recorded a 1 minute video clip. only a 10 second or less delay between SDRTrunk and Broadcastify Calls. But Microsoft XBOX Game Bar would only record the SDRTrunk window it wouldn't show Broadcastify Calls in the Microsoft Edge window. I can't upload that. Totally not what I was trying to demo.
Cool! I am interested to see where this is going!
One question I do have, and in no way am I looking to start an argument with this, do you think this will push agencies to encrypt their radio traffic?
I hope not. I just worry with the possibility of every call logged they will make efforts to avoid all this information from being so easily accessible to the public.
Thank you @blantonl for all you do to keep RR going!!
One question I do have, and in no way am I looking to start an argument with this, do you think this will push agencies to encrypt their radio traffic?
I hope not. I just worry with the possibility of every call logged they will make efforts to avoid all this information from being so easily accessible to the public.
Thank you @blantonl for all you do to keep RR going!!
Last edited:
In every case of advancement in this community, there have been agencies that love what we're doing, and those that don't like what we're doing. Some agencies will actually use our platform internally. Some won't. Some will use it as a drive to more encryption - similar to when scanners were released to the public, or when trunktrackers came out, other agencies won't care.Cool! I am interested to see where this is going!
One question I do have, and in no way am I looking to start an argument with this, do you think this will push agencies to encrypt their radio traffic?
I hope not. I just worry with the possibility of every call logged they will make efforts to avoid all this information from being so easily accessible to the public.
Thank you @blantonl for all you do to keep RR going!!
Broadcastify calls will still honor our terms of service to not allow the public to listen to law tactical etc. Nothing changes there. Even on Broadcastify Calls. Call Ingest providers will be able to access everything they send to us.... which is one of the side benefits of being an ingest provider.
One thing is for certain - new systems are going to be delayed on implementation, purchase, etc.... because of the drop in Tax Revenues.
so, to honor that - my response above will be the final response to this question. Any others pontificating or throwing their 2 cents in will be deleted.
Thank you. Great answer. Again thank you for all you do to keep this site going!!In every case of advancement in this community, there have been agencies that love what we're doing, and those that don't like what we're doing. Some agencies will actually use our platform internally. Some won't. Some will use it as a drive to more encryption - similar to when scanners were released to the public, or when trunktrackers came out, other agencies won't care.
Broadcastify calls will still honor our terms of service to not allow the public to listen to law tactical etc. Nothing changes there. Even on Broadcastify Calls. Call Ingest providers will be able to access everything they send to us.... which is one of the side benefits of being an ingest provider.
One thing is for certain - new systems are going to be delayed on implementation, purchase, etc.... because of the drop in Tax Revenues.
so, to honor that - my response above will be the final response to this question. Any others pontificating or throwing their 2 cents in will be deleted.
Will this eventually turn into a more dumbed down version (more user friendly for those of us not linux guys) where a guy can buy a few RTL SDR dongles and download software from you and have very little configuration to be able to stream to you?
I am a feed provider but want to add to what i do but am wanting to use this with windows machines.
I am a feed provider but want to add to what i do but am wanting to use this with windows machines.
yes sir - we'll get there soon. Be patient... lots of work to do right now with features and functionality on the infrasturcture and front end to the calls system.
Once we get that nailed down we're going to focus on equipment out in the field for broadasters...
I know its still in the early stages. I was looking for the confirmation of the simplified version. Which you have now confirmed. So setting the patients meter to maximum.
Thanks.
Thanks.
I was wondering if until an EZ Bake solution is in place, if anyone who has set one up would be willing to share a working Pi Buster image? I'm having a b!tch of a time with it because some of the prerequisites are trying to download files via IPv6 (which I do not have) and it borks the install.
- Status
Similar threads
