gt; bDeviceClass 0 (Defined at Interface level)
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 64
> idVendor 0x13d3 IMC Networks
> idProduct 0x3213
> bcdDevice 0.01
> iManufacturer 16 DVB
> iProduct 32 704DTVBOX
> iSerial 64 0008CA123456
>
> any sugges
> On Saturday 26 January 2008, Rob Clive wrote:
> > This device appears to be supported (card=94) but doesn't seem to work
> > consistently. Initially it's loaded OK but after a fairly random time
> > starts putting messages in the log "could not write to tu
k of
short i2c buses) but I cannot see if it's been fixed. Can anyone help?
Rob Clive
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Hi,
The datasheet for the zl10353 is freely available on the Intel support site.
Intel now call it a CE6353, the datasheet is D55752.pdf.
It seems to include everything, pin allocation etc.
Can this be used to improve our zl10353 driver ?
Rob
>
> For best results, use the master repository:
>
> http://linuxtv.org/hg/v4l-dvb
Has it got the tuner fixes for the zl13
Rob.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
cted in my kernel.
Rob.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
are very likely to have other HID devices on the system (ie - keyboards,
etc). Also, udev does not guarantee unique device names, so you may
have to write a udev rule to ensure you get a consistent device, or use
the /by-id/ paths in /dev.
Rob Browne wrote:
> Changed to kernel 2.6.21 now Di
Changed to kernel 2.6.21 now Divco remote will not work. Worked in 2.6.20.
Lirc log - error reading hiddev0
So it found the device, but is having trouble reading it.
Rob.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin
Hi,
In dvb-pll.c
freq = (div * stepsize) - offset
From debug get these values
freq = 19167 div = 1367
So i calculated offset using
( 1367 * 16) - 19167 = 26165755
What am i doing wrong, offsets are in the range of 125000.
Cheers Rob
Uwe Bugla wrote:
Original-Nachricht
Datum: Wed, 28 Feb 2007 00:19:40 +
Von: Rob Beard <[EMAIL PROTECTED]>
An: linux-dvb@linuxtv.org
CC:
Betreff: [linux-dvb] Pinnacle PCTV Sat Pro PCI DVB-S Card
Hi folks,
I was wondering if someone could possibly advise m
Capabilities: [40] Power Management version 2
More details on the card can be found at:
http://www.pinnaclesys.com/PublicSite/uk/Products/Consumer+Products/PCTV+Tuners/PCTV+Digital+PVR+(DVB-S_DVB-T)/PCTV+Sat+Pro+PCI.htm
If anyone could help I would be really grateful.
two cards and used the good
one to do the scanning, then use that list with the DibCom driver.
Saying that, you may find that trying a different initial channel list
will help.
No idea if it's useful, but try this one: (Although it's not VHF only
UHF).. (Attached - all UHF stan
I have a dreambox connected to the lan here with a Sk* UK Free sat
card in it.
I would like to know if there is anyway I can use the card reader and
cam from my linux box on the same subnet to view Channel 4 and 5
using freevo / mplayer?
I have SkyStar 2 which uses the b2c2_flexcop_pci mo
I've recently come back to the MSI Megasky stick, having been busy at work
for a while and am delighted with the progress which has been made!
I've used the code from the megasky tree, and now have a fully functional
digital tuner.
Thankyou very much!
Rob Bacon
On Oct 19 200
?
> >
> > Could do. I just didn't want to allow the user the option of setting
more
> > than one presentation/dfc format at the same time and the driver having
> > additional sanity checks. What do you think?
>
> I think the implementation will already be implemented using
> switch() or similar, so sanity checks come for free. It might
> be confusing if something which looks as a bitset cannot be
> used that way, but we already do the same with other enums.
OK, I've updated the patch to make it all bitmasks. ;^)
Cheers,
Rob : )
(See attached file: video2.patch.gz)
video2.patch.gz
Description: Binary data
enum "dvb_video_video_format" to the
"dvb_video_sequence_header" struct. This allows the video format (e.g.
PAL/NTSC/SECAM) to be determined.
Any problems or comments, please let me know.
Best Regards,
Rob : )
(See attached file: patch_video.h.gz)
patch_video.h.gz
Description: Binary data
very picture header (i.e. 40ms).
Thinking about it, I don't see a problem with the video driver extracting
the AFD information in the user-data and adding that to a field in the
dvb_video_sequence_header with a FLAG to indicate this. Would this be more
appropriate I wonder?
Cheers,
Rob : )
eze the display frame but the video decoder
keeps running in the background?
Does "DVB_VIDEO_CONTINUE" start playing back immediately or should it wait
until you have received say 2 reference frames first to ensure that no
artifacts are generated? I guess these questions are related to how we
describe/comment the ioctl functions, as they are probably h/w dependent.
Thanks Again,
Rob : )
cide what presentation format to
display.
BTW, would it be useful to have an ioctl somewhere in the API to setup the
WSS in the CVBS line 23? This would allow an MHEG application or AFD to
set the appropriate WSS for a connected analogue chassis.
Cheers,
Rob : )
14:9 with pan&scan vectors
> does actually exist in the real world?
>
At present, I haven't seen any pan & scan vectors at all in the UK. So I
doubt if 14:9 pan & scan would ever be used - only 4:3.
Cheers,
Rob : )
P.S. I'll knock up some patches and submit to you as soon as I can.
exclusive option which I believe is incorrect.
As always, its nice to hear from you DVBers.
Cheers,
Rob : )
[EMAIL PROTECTED]
lin
ioctl and 1s elapsed).
Rob : )
[EMAIL PROTECTED]
link.Com
uitably on either a 4:3 or 16:9 tube. Please refer to
the DTG document in Q4 for more details.
Look forward to hearing your response.
Cheers,
Rob : )
st).
It would be nice to have this linkage between the h/w resources and either
an ioctl or open syscall, inherently preventing this situation of multiple
processes reading the same data (from different kernel buffers). If a
system needed to allow this simultaneous access to the data, then a
wrapper/layer could be devised in user space to present the illusion of
multiple data producers.
What do you think?
Rob
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
st
provide the flexibility that a DVB API should have.
Let me know what you think
Cheers,
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
i is much cleaner and provides finer granularity
in terms of section filter control/buffer management. Having a linkage
between the fd, section filter id, and kernel buffer makes more sense than
fd, multiple section filter ids and single common kernel/hw buffers. So
let's put this one to bed once and for all!
Cheers,
Rob : )
P.S. Sorry if I have given you a headache on this one ;^)
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
rlink specific but if you ever deal with a few well known
UK STB design houses you will see that this is how they operate -
strangely. ;^) So, really I/we could do with finding out if there is a
real technical reason for performing these steps independently (rather than
in one go). So if the
upport customers who insist on having a single fd to read back all the
section tables associated with a single PID :(
Thanks Anyway,
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
common area of memory. In this case, you again need to
setup each pid filter that you want to record, but there are multiple
record filter "slots". So what do we now class as a "feed" - a filter or
buffer or both the filter and buffer connected together? Does the V4 API
handle all these record implementations without any fuss?
Finally, what are the meaning of the newly added record methods in the
filter bank:
try_add_recording_pid
commit_recording_pid
confirm_recording_data
etc.
TIA,
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
t? I guess the idea here is to
allow quick navigation of the recorded data by reading the log to find an
event, and "jumping" to the actual stored data. Please feel free to
elaborate on this or correct me.
Thanks,
Rob : )
- Forwarded by Rob McConnell/Zarlink on
e until we perform one of the demux IOCTLs to setup a
feed/filter. Only here, is when we know whether we can actually get a
handle to a feed/filter. Not really that elegant is it?
Other than that, its good to see some actual code being bashed out - it
tests the V4 API proposal.
Cheers,
Rob : )
-
) and now my nexus-s remote
is working for my freevo box - which uses lirc. :) Not everyone with a
DVB card uses VDR. :P Too bad Freevo lacks DVB support but its comming,
at least to the extent that mplayer, xine, and szap support it.
Cheers,
-Rob
0x3d KEY_POWER
0x3b KEY_GOTO
0x00 KEY_0
0x01 KEY
s although not yet sure if I'd like to use the mpeg
decoder / tv-out.
-Rob
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
set the value of the "speed" parameter ?
Don't know this one.
Hope this help.
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
e option at
compile time with a #define depending on the underlying h/w. Could you
envisage anyone wanting to use both methods at run-time? This would,
however, make the underlying kernel code v. tricky and bloated and would
probably not be terribly efficient.
Just my thoughts at the moment...
bles to be
allowed up to user space and the middleware to perform the filtering on the
single fd.
I think we shouldn't be too blinded with h/w that we are familiar with on
cards, but rather look at what is out there on real STBs as well. Having
both methodologies would allow one to have optimum performance wrt the
actual h/w (less time spent in kernel mode doing copies/etc.) and would
also provide a flexible interface to the mad user-app folk out there ; )
TTFN,
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
make sense to keep these global flags
or
> > per pid flags or ignore them completely?
> Hm, I think these are ofter per-PID, but I don't know if recording
> filter hw supports them, too. I think it's best to ignore them
> as I doubt that applications would make use of th
DVB_DMX_DEFAULT_THRESHOLD.
This could function similarly to the existing V3 implementation for
backward compat.
> The intention is to make DVB_DMX_SET_* to replace any previous filter
> on the same fd, so it can be used to quickly change filter settings.
That's great!
Thanks,
Rob ; )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
t's all the comments I have at the moment on the demux side of
things
> > for V4. I think it is probably best to keep with this API for the
moment
> > rather than the alternative one, as it keeps things relatively
> > straightforward and is not too distant from the current V3 A
n would be for the filter to be stopped
internally, registers reset and the new filter spec. applied before the
filter is restarted. If not, does it simply return -EBUSY? The same
question also goes for the ioctl "DVB_DMX_SET_PID_FILTER".
That's all 4 now,
Rob : )
--
Info:
eeps things relatively
straightforward and is not too distant from the current V3 API. What do
other people think?
Cheers,
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
not I would be willing to build one and post the data I collect.
I can easily handle building the device, the only question is, where do I
connect it to monitor the activity on the dvb-t card? ;)
thanks,
rob
On Tuesday 18 November 2003 9:07 pm, Holger Waechtler wrote:
> Martin Stubbs wrote:
>
ok I'll have a go at doing that, I'll post back to the list when I have
any more information.
I've also contacted avermedia and asked if they would be willing to supply
any information. you can always ask ;)
rob
On Sat, 15 Nov 2003, Holger Waechtler wrote:
> [EMAIL PROTEC
Hi,
I would be willing to spend time working on this driver. Where can I find
the relevant information on what's to be done?
thanks,
Rob
On Fri, 14 Nov 2003, Martin Stubbs wrote:
> Holger,
>
>
> > > I have my Avermedia DVB-T card working successfuly with Mythtv but
lso like to know if the remote that came bundled with the
avermedia card can be used with lirc, how do I find out about that?
thanks,
Rob
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
nologies Inc: Unknown device 0761
00:0e.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture
(rev 11)
Subsystem: Avermedia Technologies Inc: Unknown device 0761
If anyone could point me in the right direction to sort this out I'd be
very appreciative.
Once I have the card work
.
Thanks,
Rob
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
drivers working for my card.
Are people successfully using particular dvb/CA/CAM models together with
North American sat providers?
Thanks for any info or leads,
-Rob
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
roblem of the Xlet developer or the box manufacturer ;-(
OK, I'm not up on MHP, but it does sound a potential problem for
STBs/iDTVs.
> > > OK, I will update the dvb-kernel-v4 header files on Monday according
> > > to my liking.
> > Ok. Don't work to hard this
tatic value or will we always use the experimental
value of 250?
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
Hi Folks,
Quick Q what is the major device number going to be for the V4 API? Do
we currently use a non-experimental number on the 2.6 series?
Cheers,
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
only system without
> the major/minor limitations. Kudos to the guy who crippled this.
Dough!
> > I think its time to come up with some real API header files again. If
we
> > propose both ideas in different files and let people comment on them,
then
> > we may get more feedback.
> yes, please do so -- maybe then it gets clearer why your approach might
> get simpler at the end.
I'll give it a shot when I get a bit of time.
Off home now, so probably speak 2U all on Mon - via the magic of email
Have a good one!
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
ts code and adds a little of its own to setup the h/w
correctly.
> > I think its time to come up with some real API header files again. If
we
> > propose both ideas in different files and let people comment on them,
then
> > we may get more feedback.
> OK, I will update the d
nded it. Output "channels" are managed by connecting
> devices to the demux/filter fd, or (in case of recording) by opening
> a second fd for the second recodring channel.
Ah, probably what I forgot to mention was that each stream coming out has a
header prepended to the actual filter
f course you would still need
the .../videoX and .../audioX devices.
Would you need to have the "dvb_dmx_output_format" struct included in the
new "dvb_dmx_decoding_filter" as I don't know of any A/V decoders that can
accept a TS packet input (only PES or ES)? Anyone k
output channels (#1 through to #4 quite easily).
e.g. /dev/dvb/adapter0/demux0/pidfilter0 -> source stream #1, output
channel #1.
/dev/dvb/adapter0/demux0/pidfilter1 -> source stream #1, output
channel #2.
/dev/dvb/adapter0/demux1/pidfilter0 -> source stream #2, output
channel #3.
/dev/dvb/adapter0/demux1/pidfilter1 -> source stream #2, output
channel #4.
I have also run this over other h/w that I know and it seems to fit the
bill. Please make any constructive comments...
Good work Guys!
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
Proprietary in our case.
> I would be interested to know what you have in mind for the scaler
> API, and how you plan to implement reliable pan&scan.
I'll let you know when I have re-read the scaler documentation and spoken
with the softy who's been named to do this.
Later,
areas such as video decoding and video scaling. This would more closely
map our h/w.
Hope this makes sense.
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
his keeps things simple and is also consistent with the audio/video
device APIs.
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
p the ability to write to the logical demux device directly,
but have no problems with other input devices being created. I guess
another TODO would be to cater for DMAs from say memory to the demux device
for playback of data from a DVD/HDD.
> Currently I think it's best to keep the frontend devices
> as-is, and just add new non-generic input device types.
I agree.
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
data filtering or retrieving the
random access indicator for determining when a video sequence header
starts. The h/w buffer would contain just the TS header and adaptation
fields.
As for the DMX_SET_EVENT_MASK and DMX_GET_EVENT ioctls (please prefix with
DVB_), these would have to be is
/w.
I don't mind which way we go as long as the requirements are met - which I
believe they are.
Cheers,
Rob :^)
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
> Hi Rob,
> So this is only a change in the semantics.
> The API needs not need to be changed.
Yes. Just clarify its meaning.
> The autostart can be given with the set ioctl.
> The add/remove ioctl only have the pid as parameter.
> Start iioctl needs to be called after
Hi Tom,
Yes this is correct.
Rob : )
"Haber, T
a filter issue the
DVB_DMX_DEL_PID_FILTER ioctl.
OK, does this look reasonable?
Rob : )
the video/audio/subtitle PIDs all in one go, then at least we
wouldn't have this worry.
Rob :^)
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
TL_BASE, 0x4e, struct dmx_event)
>
>
> The DVB_DMX_CLR_STC_COMPARE operation would be done by
DMX_SET_STC_TRIGGER
> with "enable" == 0.
> OK?
This looks good!
Rob : ^ )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
X_SET_PID_FILTER with an array of
PIDs to set and start immediately using the DVB_DMX_IMMEDIATE_START flag,
we can nicely obtain this requirement.
Do these ideas sound reasonable?
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
dn't even see your helpful comment above the #define line.
What a dork head I am 2day!
At least we are thinking the same on this :-)
Cheers,
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
waiting on this event and the
"DVB_DMX_CLR_STC_COMPARE" ioctl is issued on the logical demux device, then
the process would wake up and the event returned would be
"DVB_DMX_NULL_EVENT".
Any more thoughts on putting this functionality in to the V4 API?
Cheers,
Rob : )
--
In
in memory to a HDD or to another bit of h/w to preprocess
the data. Also, if someone wanted to follow the MPEG-2 systems spec and
create a TS from its parent TS (albeit timings would be a bit off), then
this could be a useful stab at doing it.
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
In this case, why not specify the
pid value as in the proposition for the ADD/DEL ioctl above?
Any thoughts?
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
ID_FILTER accepts the fd but no
argument to specify which PID filter to remove. Can we please add the PID
value as an argument to distinguish which PID filter to remove.
Thanks,
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
es to cater for the h/w that could
simultaneously demux and decode N out of M possible sources, then would you
be able to "write" the same data to each logical demux device fd? How
would you allow for each logical demux to demux a part of the same
TS/PS/PES?
Rob : )
--
Info:
To
method in the TS Feed API be used to set a h/w
buffer/circular buffer instead of a vmalloc if NOBUFS is not defined? When
would you use this circular buffer when NOBUFS is NOT defined?
Thanks,
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
cter device exactly what we need
> without much overhead due to abstraction/generalization.
I'll have a look - thanks!
Do we intend to add extra #defines from ca.h in V3 to dmx.h in V4?
e.g. struct ca_descr_info
Cheers,
Rob ;^)
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
don't care much, I just thought
> the current ci.h is simpler than the old ca.h, and thus better ;-)
Keeping it simple is with 1 CI device per slot sounds good.
BTW, I guess it's no use to have an API between a smart-card and a host as
this will be confidential info. Right?
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
ers with more than one).
> If you have one CI device for each slot, you might want to call
> them ci0_0, ci0_1, ci1_1 etc. where the first number is the CI adapter
> unit and the second the slot. Your source setting calls to ciN_0 would
> be valid for all ciN_X and so on.
I have no problems with the adapter/slot method. Any more
comments/suggestions folks?
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
and this removes the old section filter from the feed.
> An implementation of the new API will just keep a table of filters for
> each file descriptor instead.
Agreed.
Thanks,
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
o demux so that we can setup the required
> > buffer size/thresholds or other characteristics.
> My experience is that it's bad to code defaults in the driver. It's
> better to have buffer size/thresholds or other characteristics in the
> API and have the app designer pass ap
ess wait for an event to occur?
> I don't think that there's a substantial speed difference. Signals are
> just a mess wrt multi-threading.
Agreed.
> > Would it make sense to have the ability to have a DVB_DMX_SET_STC_CMP
ioctl
> > for h/w that uses it? For h/w th
ates a threshold interrupt */
Numbers greater than say 100 would actually mean the number of bytes to
receive before generating a threshold interrupt. e.g. If the value of 256
is passed to the ioctl, then each time 256 bytes are received by the h/w
you will get a threshold interrupt and this number of bytes would then be
gobbled by the callback function.
Hope this clarifies the situation : )
Cheers,
Rob ; )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
eneral input device" model, you could have
> e.g. two frontend input devices and two CI input devices. Then add
> a DVB_CI_SET_INPUT ioctl which allows simply to select frontend0/1. OK?
Yes, I agree - this was my thoughts exactly. Having a SET_INPUT ioctl
would be similar to the wa
he ability to route an input TS from say an
external demod to a C/A module and then into the logical demux device is
covered. Also, h/w that does not have a C/A or C/I router will still
function the same i.e. demux selects the required front_end.
Thanks for the comments!
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
ocess that the
STC compare event occurred. Which is quicker, sending a process a signal
(e.g. SIGUSR1) or having the process wait for an event to occur?
Would it make sense to have the ability to have a DVB_DMX_SET_STC_CMP ioctl
for h/w that uses it? For h/w that didn't support it, you co
be the best approach (as we have all
learnt a lot more about DTV over the years and the existing s/w certainly
has limitations).
That's all 4 now...
Cheers,
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
o have a PVR board design that
is roughly the size of a VCR cassette that does have a ethernet port. We
don't manufacture the end product, but we do have app reference designs.
Hope this helps,
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
TL be setup
to set the compare register in the h/w and then an async event be returned
to user-space when the STC reaches the value programmed in the STC compare
register?
Thoughts?
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
.
BTW, what make of TV is it and model?
Hope this helps,
Rob ;-)
r FilmFour now. :( Never mind - FreeView is kicking out +50 channels
that
> > are
> > completely free : )
>
> Hi Rob,
> Thanks for the clarification, and the speedy reply :) Now.. if only the
> postman with my Nova-t would be as fast..
Hi Tim,
You can check out the
msg00246.html
Hi Tim,
Unfortunately these are "remains" from the now defunct ITV-Digital in the
UK.
Everything now is completely free-to-air meaning that you don't get the Sky
channels
or FilmFour now. :( Never mind - FreeView is kicking out +50 channels that
are
c
f having to use
the write syscall? What about mmaping instead to speed things up?
Do we currently support Audio ES in the API? If not, then this needs to
be added as my h/w supports this
Hi Thomas.
What about handling of VCDs that are encoded in MPEG-1 PS format? We
shouldn't forget about this either ;-)
Regards,
on TS priorities is an option that the Canal +
spec requires, but I haven't seen anyone (broadcaster) use it yet. If
anyone has, then please let me know ;-)
That's
uot;flag" field in the filter
structs if we wanted to or just have some other IOCTLs to setup the policy.
What do you think?
That's all for now.
Rob ;-)
the h/w
buffers to a DVR for a record operation and from the DVR to the internal
h/w buffers for a playback operation? I would rather use DMA than the
read/write syscalls as it would be more efficient in terms of memory/cpu
#2).
Any more thoughts out there?
Best Regards,
Rob ;-)
s would be much appreciated. I don't mind contributing either
;-)
Rob : )
--
Info:
To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as
subject.
rward my kernel config file if required,is there
some external driver that I am missing on which there is a dependency??
Rgds
Rob Mason.
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be s
10:35:33 nova dvbd[1239]: ioctl VSFRONTEND: Invalid argument
Jul 23 10:35:33 nova dvbd[1239]: exiting
Jul 23 10:35:33 nova dvbd[1239]: ioctl SHUTDOWN[0]: Bad address
Jul 23 10:35:33 nova dvbd[1239]: ioctl SHUTDOWN[1]: Bad address
Any ideas what I'm doing wrong?
1 - 100 of 103 matches
Mail list logo
