Global Pre-up / pre-down and per stream pre-up/pre-down about mumudvb

[braice]

I'm controlling mumudvb with systemd, which ensures it is faster up/down.
In another issue we discussed the card=auto statement, and what this would do to the traditional pid file system (bound to the card, not the frequency/polarization/position or simple Network ID).

As I worked my way through the systemd (everything is new) horror, I would have to say, this has much more future and potential as spawning extra processes.

As a simple solution outside the main source I can recommend using some IPC, even making a NOTIFY like session in the http "daemon" part. This keeps the process management out of the streaming software (keeping it portable across libc/kernels etc.), and also solves the problem.
Right now I'm tail -f .. | read | case on the log, to have the same effect. inotify on the parsed config would only add fractions of a second delay.

To summarize:

1. inotifywatch the pid/config
2. tail the log
3. proper systemd
4. some IPC concept
   are my arguments against throwing more logic in the core software, and having related software still attached.
   I hope some of this solutions help you in the short term.

[m0yellow]

The trigger from #25 could include this use-case, as mumudvb definitely shouldn't wait for the external to finish before setting up ... the only use-case for a pre-up would be to manipulate the IP Stack allowing extra multicast addresses. But this is far fetched. everything else (including pre-down) can be run after a trigger for channel down has been fired, as mumudvb doesn't (and shouldn't) wait for removing a multicast when the channel disappeared.

[m0yellow]

maybe I should note that I'm the one working mumudvb+systemd, still learning on dbus to handle my notifying need.

[braice]

Perfect ! please keep us updated

THanks

2013/12/5 m0yellow [email protected]

maybe I should note that I'm the one working mumudvb+systemd, still
learning on dbus to handle my notifying need.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/23#issuecomment-29886018
.

[m0yellow]

As Braice doesn't like dependencies ;) this rules out snmp, dbus, and whatever pulls in another library. I would count the options as HTTP Push, HTTP get/post (without libcurl this gets nasty really quick), handcrafted snmp (uuuueehhhh run run ….), xmpp (already too much hand crafted xml without dtd in here).

I would suggest exploring the http push route, we already have most data in json, this would be a perfect fit for a websocket implementation. I recently discovered FreeSWITCH uses this for a live view of running calls http://wiki.freeswitch.org/wiki/Freeswitch_Portal .

This would allow to close this and #25 in one go.

[braice]

I don't like mandatory dependencies, but if you have easy example with dbus or other I think it is worth having a look into it.