Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.


Monitoring acquisition progress externally

  • Since quite some time, I do use nxtvepg for providing EPG data to my VDR system. I configured nxtvepg once for correct acquisition and do now use it via cmdline (nxtvepg -acqonce full -daemon -nodetach -provider xxx; ...; nxtvepg -noacq -provider merged -dump xml).

    However, sometimes it would be nice if I could somehow display a progress bar during EPG retrieval.

    The easiest way for this seems to be to take epgacqclnt.c and build a simple commandline/gui client around it which only display the current progress of the retrieval daemon *and* exits automatically when the daemon is finished.

    Now I wonder whether something like this is already available somewhere and/or if there's a more easy way to accomplish such a thing.

    Gernot (gernot AT

    • Martin Zi.
      Martin Zi.

      Yes ... that's want I need tooo ...

      I use it on KnoppMyth to get tv data (Kabel 1 and SF 1) for my analog channels with merged mode ... but SF 1 signal is sometimes very bad from our local cable provider and grabbing got sometimes stalled ...

      - timeout option for acquire one would be very nice like tomzo discribed

      - little asci status for commandline client will be very nice


      • Tom Zoerner
        Tom Zoerner

        > - timeout option for acquire one would be very nice like tomzo discribed 
        > - little asci status for commandline client will be very nice

        I've added both features in pre-release 2.9.0pre2. The acquisition status can be queried using the nxtvepg client with option "-daemonquery" or by directly connecting to the server port and sending the request string which is documented in the manual.

        If you need more details in the status output just let me know.


    • Tom Zoerner
      Tom Zoerner

      There's no tool yet for tracking the daemon's acquisition progress, except for nxtvepg itself. There were requests for such a thing in the past, but as it turned out the reason behind them was just to terminate acquisition after one cycle. Hence after implementing the -acqonce option there was no reason anymore to add the statistics feature to the daemon.

      Anyways, my preferred way to implement such a thing would be to add a simple protocol on daemon side. This could be a trivial ASCII based protocol which also returns statistics in text only (similar to /proc on Linux) This has the advantage that you don't need to know any nxtvepg internals on client side and can easily implement your client in Perl or some other scripting language.


    • Ok, even better. So could you give me a short hint where to start with that?

      I'm actually interested to give user feedback via GUI if the real acquisition is running and how fast etc. because it can take a looong time and it's bad just to wait two hours seeing that nxtvepg doesn't exit in blindness to finally learn that acquisition is somehow broken...


      • Tom Zoerner
        Tom Zoerner

        All socket I/O is scheduled in epgctl/epgacqsrv.c::EpgAcqServer_HandleSockets(). This is a standard select() based I/O scheduler with an additional one-second timer to poll the EPG block queue for incoming data. Statistics are sent with every AI block or every 10 seconds by calling EpgAcqServer_BuildStatsMsg()

        Since EpgAcqServer_HandleSockets() is already very complex, it would definitly have to be split before adding a 2nd protocol. You'd also have to adapt the low-level message I/O funtions, since they assume each message has a two-byte message length header which is not appropriate for a text-based protocol. If you want I can provide a draft for that (I recently re-used the code in another application where I also used a text-based protocol, so I can re-import some ideas from there.)

        In regard to "broken" acquisition: I guess it would be a good idea if the "acqonce" mode would abort acquisition if no data can be captured in a certain timeframe (e.g. 5 minutes)  This way the user would at least not wait in vain. Actually when you have multiple Nextview EPG providers such a timeout should already occur.