similar to: smbclient fails to list directory >36 entries

Hello, I'm having problems with using smbclient on a win2k share. The server runs samba 3.0.14a on Solaris 9. I want to tar the whole directory of a share. Into a file on the server What I found out so far is, that it works until a maximum file count of 35. It is not size dependant but if the file count in that share exceeds more than 35 the smbclient hangs for ever and with the time is

Greetings all, I'm trying to connect to the default shares Windows NT workstation enables for "administration" purposes but I'm not having any luck. smbclient can see the shares: [esisler@shaun esisler]$ smbclient -L ghost added interface ip=198.243.2.206 bcast=198.243.2.255 nmask=255.255.255.0 Got a positive name query response from 198.243.2.200 ( 198.243.2.150 ) Password:

I was wondering why my CD ripping was producing short files from some tracks. A superficial examination of the code shows this piece of code in vorbis-tools/oggenc/encode.c: Line 120: /* Main encode loop - continue until end of file */ while(!eos) { [...] /* While we can get enough data from the library to analyse, one

Hi, I'm working on a new ogg file chopper (porting 'hogg chop' to C). These work pagewise, ie. they just copy the pages that are needed from the input to the output bitstream. I'm modifying the last page in the output bitstream so that it has the eos flag set. The last page is always one that has a granulepos set (that of the last packet finishing on that page). But let's say

On 25-Feb-08, at 3:42 PM, Conrad Parker wrote: > ok. If the correct behaviour should be to ignore the incomplete > packet, that should also be clarified in the spec. Fair enough. What if no packet ends on the eos page? What about additional pages after the eos page? > I'd find it useful if it was not considered a structural error, as it > allows us to very simply chop files

On 25-Feb-08, at 9:34 AM, xiphmont@xiph.org wrote: > I'd say both; libogg should ignore the incomplete packet or flag a > structural error, and the spec should be clarified. I guess libogg should return -1 if you try to ogg_stream_packetout() after the eos packet. The eos flag pretty clearly applies to the *page* not the packet, so I think how that gets translated into the

Hi All, I'm using samba 3.0.10-1 on RedHat Enterprise Linux 4. I'm authentication to our PDC using Winbind and also mounting our home directory share (from Windows) onto our main Linux server such that when a user logs on to the Linux server, their Windows home directory is mounted also. I'm using the domain admin account to mount the home directory share, which I feel is

I can't seem to get a Windows XP Media Center Edition system to see a very simple print share. [global] workgroup = HOME realm = SHAUN server string = Samba Server security = SHARE encrypt passwords = No log file = /var/log/samba/%m.log max log size = 50 dns proxy = No wins support = Yes valid users = shaun admin users = shaun read list = shaun write list = shaun printer admin

Okay my smb.conf file is correct. Firewall is configured correctly to allow Samba on local network. smbd and nmbd are running. Her computer still cannot connect to my printer share. I read my Samba version wrong its actually 3.0.23a-1.fc5.1, here is my smb.conf: [global] workgroup = HOME realm = SHAUN server string = Samba Server security = SHARE encrypt passwords = No log file =

On 26/02/2008, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > > Hmm, good point. Maybe it requires a MUST specification... But then, it > would not be conformant to have a partial packet on the last page.... I'd definitely prefer that the recommendation to not have an incomplete packet on a page marked eos is a SHOULD not a MUST, so that eos pages don't need to be

Full_Name: Johnny Accot Version: 1.5.1 OS: Linux Submission from: (NULL) (198.4.83.52) Hi. I'm having a problem with the binary read/write functions. I'm writing a device driver in R (why not?) and of course I have to send a couple commands to the device. Typically, I send one byte, receive one acknowledgement byte, send another byte, receive an ACK, and so on. At least this is what

On 2008-11-13, Conrad Parker <conrad at metadecks.org> wrote: > I'm wondering if the Dirac granulepos parsing in liboggz and display > in the oggz tools is currently correct, as I'd like to do a release of > these soon. I believe it is -- although if correct support in the rest of the liboggz tools is required, a little more work may need to happen. > Here's some

I have a technical question about the vorbis granule position, but I would like to put the question into context. When a ogg vorbis stream is ripped using wget, fetch, or streamripper under Linux or FreeBSD, the resulting file has problems both with granule position and with a missing EOS. I think I can figure out how to add an EOS, but is there a way to determine the granule position in a stream

I don't know about the technicalities, but Peter Dalgaard said the offending code also causes R to come to a stop using SUSE + WINE. Is it possible to run that lot on top of valgrind? Of course, it will probably take all day ... If not, I have a clue which might help. The problem seems to lie in the "sub" routine. In the original report I used -- cut here -- gctorture() u <-

We seem to have stumbled onto an intermittant bug using smbclient to retrieve files from a W2000 server. Every so often it just ignores some files on a recursive mget. When it ignores files it always ignores the same files. The exact same command repeated again may (or may not) pick up that file. Running a DIR on the directory in question shows the same defect, sometimes the cursed file is

Hello, *Background:* The RFC 5574 suggests the RTP payload format for the speex codec. The payload formation is straight forward; the encoded frames are to be concatenated one after another. Once we have appended desired number of frames, we have to pad the stream with 01111 sort of sequence to ensure that payload ends on a octet boundary. *Observation:* I am using the speex encoder at 2150 Kbps

I have recently been using writeChar and writeBin to write binary files. These functions makes it very easy to write OS-independent files, which I am very happy with. I have however found a few issues, best illustrated by a short example > con <- file("test", open = "wb") > writeChar(as.character(c("ab", "ab")), nchars = c(3), con = con,

2008/11/14 David Flynn <davidf+nntp at woaf.net>: > On 2008-11-13, Conrad Parker <conrad at metadecks.org> wrote: >> I'm wondering if the Dirac granulepos parsing in liboggz and display >> in the oggz tools is currently correct, as I'd like to do a release of >> these soon. > > I believe it is -- although if correct support in the rest of the >

2008/10/29 Romain Beauxis <toots at rastageeks.org>: > > I am currently implementing theora for our application. > In our model for generating ogg streams, we may want to stop > a stream while not providing a new YUV data buffer for encoding. > > Current API doesn't allow such thing, since the eos flag is set by the > packetout function only when the last_p parameter

2017-06-16 10:28 GMT-05:00 Jesus Cea <jcea at jcea.es>: > On 16/06/17 13:18, Marvin Scholz wrote: >> The source client is supposed to encode the metadata into the stream, >> not use any endpoint whatsoever to send them, for Ogg and >> other supported formats. There is nothing confusing about this. The >> reason this is different for MP3 and AAC is, that it is